Difference between revisions of "BoostC Explaining Dot H Files"

From OpenCircuits
Jump to navigation Jump to search
m (BoostC Explaining BoostC.h moved to BoostC Explaining Dot H Files: title needed changing)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
Change Name to BoostC System Header Files
+
Draft Not quite Ready
 
 
 
 
 
 
Draft Not Ready
 
  
  
Line 26: Line 22:
  
 
== BoostC.h ==
 
== BoostC.h ==
 
 
  
 
BoostC.h is almost always included, but via System.h, so you may not “see” the include.
 
BoostC.h is almost always included, but via System.h, so you may not “see” the include.
Line 68: Line 62:
 
_B in asm represents the addres of the variable B in the C program.
 
_B in asm represents the addres of the variable B in the C program.
  
Additionally from reading this macro we can see that BoostC stores 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.
+
Additionally from reading this macro we can see that BoostC stores the low byte in low memory and the high byte in higher memory.  This is called little-endian.  Useful to know if you want to do byte manipulations on multibyte data.
  
 
=== Delay functions generated by linker ===
 
=== Delay functions generated by linker ===
Line 84: Line 78:
 
== More Reading ==
 
== More Reading ==
  
see inline functions for more information on inline functions and #define.
+
see [[BoostC Inline Functions]] for more information on inline functions and #define.
 
 
  
  
 
== Other project Files ==
 
== Other project Files ==
  
*.cof  not a text file, purpose unknown
+
*.cof  binary file, debug information. 
  
 
*.stat  text file, purpose: Linker Function Resource Usage Dump
 
*.stat  text file, purpose: Linker Function Resource Usage Dump
  
 
+
*.obj      binary file, source code compiled into object code
*obj      not a text file, purpose unknown
 
 
 
  
 
*.lst    text assembler code ( no ref to source )  output of xx input to yyy
 
*.lst    text assembler code ( no ref to source )  output of xx input to yyy
  
 +
*.csam  mixed source and assembler code  output of xx input to yyy
  
*.csam   source and assembler code   output of xx input to yyy
+
*.brws   text, symbols etc and their source code reference.
  
 +
*tree  call tree in text format, display in ide by....
  
*brws  text, symbols etc and their source code reference.
+
[[category:PIC]][[category:BoostC]]
 
 
*tree  call tree in text format, display in ide by....
 

Latest revision as of 20:35, 16 March 2009

Draft Not quite 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.

System.h[edit]

Should almost always be included in all your files. It has limited functionality, largely a bridge to other include files. For the boostC compiler these files are:

  • BoostCPic18.h defines for the 18 series chips
  • BoostCPic16.h defines for the 16 series chips
  • Boostc.h defines and other utility stuff for the compiler.

Apparently the compiler reads the target chip and effectively #defines a value for _PIC16F722 or whatever for the chip that you have designated the target chip.

Links for the macro processor and related

http://publications.gbdirect.co.uk/c_book/chapter2/textual_program_structure.html 2.3. The Textual Structure of Programs

http://publications.gbdirect.co.uk/c_book/chapter7/ 2.3 The Textual Structure of Programs

BoostC.h[edit]

BoostC.h is almost always included, but via System.h, so you may not “see” the include. The following refers to section within BoostC.h, pull up a copy while you are reading this.

Helper macros[edit]

ex:

    #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.


MAKESHORT[edit]

    #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 Token pasting.


see: 7.3.2.3.Token pasting


with token pasting when

   asm movf _##lobyte, W 

is processed in MAKESORHT( A, B, C ) becomes

   asm movf _B, W 

_B in asm represents the addres of the variable B in the C program.

Additionally from reading this macro we can see that BoostC stores the low byte in low memory and the high byte in higher memory. This is called little-endian. Useful to know if you want to do byte manipulations on multibyte data.

Delay functions generated by linker[edit]

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[edit]

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[edit]

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

More Reading[edit]

see BoostC Inline Functions for more information on inline functions and #define.


Other project Files[edit]

  • .cof binary file, debug information.
  • .stat text file, purpose: Linker Function Resource Usage Dump
  • .obj binary file, source code compiled into object code
  • .lst text assembler code ( no ref to source ) output of xx input to yyy
  • .csam mixed source and assembler code output of xx input to yyy
  • .brws text, symbols etc and their source code reference.
  • tree call tree in text format, display in ide by....