mE's mikroPascal PRO for PIC tips, tricks & quirks

• Delays library (__Lib_Delays)
• Strings library (__Lib_String)
• Conversions library (__Lib_Conversions)
• Internal EEPROM library (__Lib_EEPROM_256 and __Lib_EEPROM_1024)
• System library (__Lib_System)
• Fixed-point math library (__Lib_Math - two versions)
• Floating-point math library (__Lib_MathDouble - two versions)
• Floating-point functions library (__Lib_Trigon)
• Trigonometric functions library (__Lib_Trigonometry)

	- both text and graphics may be drawn anywhere on the screen,
	- ability to draw on virtual screen(s) placed in RAM,
	- 'packed' bitmap format implemented saving program space,
	- clipping rectangle for most graphical functions,  
	- routines for copying whole, or part of the screen from GLCD to RAM and back,
	- routines for icon drawing (icons from RAM or ROM), inverting, and horizontal shifting,
	- both fixed-width and variable-width fonts of any size (created, for example with Octal's
	  GLCD Font Creator) may be used,
	- increased speed performance over the standard lib, especially visible for higher clock
	  frequencies,  
	- hardware-dependent part is separate and may be modified to fit particular GLCD controller. 
	

	- results of runtime calculations may differ from compile-time ones
	- while evaluating in main a byte holding sbits declared in a unit
	  optimiser may overlook changes applied to single bits
	- applying sfr modifier to a variable declared at GPR absolute address makes 
	  the linker believe it's indeed in SFR space, so it's real space is freed 
	  and may be taken by another variable
	- FSR registers are not saved in ISR unless used in assembly  
	- modifying variables with the use of FSR registers may confuse optimiser
	- in some cases optimizer may fail to notice that part of a variable was changed 
	  using Hi, Lo, Higher, or Highest operators
	- calling RS485Master_Send routine with TFT lib checked in Library Manager leads 
	  to linker demanding declarations of the latter's sbits  
	

	- internal representation of variables
	- storing/accessing variables	
	- speeding up sequential memory access 
	- reentrancy
 	
	

	- labels declared in Pascal
		- in main:   L__main_<label_name>
		- in subroutine:  L_[<unit_name>]_<routine_name>_<label_name>
	- other labels	
		- subroutine beginnng:  [<unit_name>]_<routine_name>
		- subroutine end:  L_end_<routine_name>
		- beginning of main: _main
		- end of main: L_end_main 
	- labels in asm block: <label_name> (label by itself requires colon)
	
	Note:  optional [unit_name] is added for private routines - those that do not have 
	       their prototypes declared in interface section of a unit.
	
	- global vars: _<var_name>
	- SFRs (always global):  <SFR_name>
	- vars declared in implementation section: <unit_name>_<var_name>
	- local vars: <routine_name>_<var_name>

	- global vars declared with rx specifier: _<var_name> (no change)
	- local vars rx'ed: <routine_name>_<var_name> (no change)
	- vars declared in implementation section rx'ed: <var_name>
	
	- global constants: _<const_name>
	- constants in unit implementation section: <unit_name>_<const_name>
	- local constants: <routine_name>_<const_name>
	- sbit: regular sbits (GPR) need an underscore in assembly while SFR ones do not:
	    bcf _mybit,BitPos(_mybit)   // mybit: sbit at mybyte.7;
	    bcf SFRbit,BitPos(SFRbit)   // SFRbit: sbit at PORTB.7;
	- bit variable is used in assembly like sbit one:
	    bsf _mybit,BitPos(_mybit)   // mybit: bit;
	  
	- vars & constants declared with register specifier preserve names from Pascal  

	- function result: <routine_name>_local_result
	- parameter of a routine: FARG_<routine_name>_<par_name>[+offset]
	
	- addresses of variables, constants and labels may be obtained with lo_addr (this 
	  one may be omitted), high_adr and higher_addr operators, like
	    MOVLW       _constant
	    MOVWF       TBLPTRL 
	    MOVLW       hi_addr(_constant)
	    MOVWF       TBLPTRH 
	    MOVLW       higher_addr(_constant)
	    MOVWF       TBLPTRU
		
	Note: global vars or constants are those declared in main unit or interface section 
	of another unit while local ones are those declared within a routine.	
	

	- as compiler knows variables' distribution, adding accessed memory specifier 
	  in user asm block for PIC18s is not necessary - in fact any such specifier 
	  is ignored (though both ACCESS and BANKED constants are declared in any PIC18
	  processor def file, neither produces any effect)
	- in spite of mP Help stating otherwise, Pascal comments may be used in embedded 
	  assembly code without negative effects seen when using semicolon (see Warnings)
	- starting from v 4.80 one may include in code text files containing assembly 
	  with help of $I directive (as {$I filename} or {$I "filename"})	  
	

	- there's no macro assembler in mP PRO so only plain instructions are interpreted
	- for final assembly code one should look at the *.lst file - asm files, prepared 
	  for every unit, may differ from the real code (are prepared before final
	  optimisation) 	
	- use of GOTO and CALL instructions is severly limited as labels in assembly 
	  (as well as all other labels but the routine start) are local to a routine; 
	  this means that one may only jump/call within a Pascal routine or call (jump to
	  beginning of) other Pascal routines (within Pascal scope rules)
	- semicolon does not act as real comment in asm block ('end' or apostrophe are 
	  interpreted by compiler and Code Explorer); also Code Assistant gets confused 
	  by comments in assembly containg keywords, like 'end' or 'case'
	- one has to use explicit numbers in LFSR instructions as FSRx constants are declared 
	  as addresses (equal to FSRxL). In other words, notation known from MPLAB
	
	      LFSR FSR0,_some_var
		  
	  has to be replaced by
	
	      LFSR 0,_some_var
	 - for code larger than 64K additional GOTOs appear at $1C as compiler doesn't use 
	   addresses larger than two bytes. The list of GOTOs includes all routines above 64K, 
	   jumps for indirect function calls, and ISRs. Most of the GOTOs are not used if the code 
	   is small, as compiler uses RCALLs (relative calls) whenever possible. Unfortunately, 
	   if the call range is greater than 1k words, regular CALL is made to one of the GOTOs
	   rather than directly to a routine	   
	- any change to STKPTR causes simulator break 
	- simulator freezes if any of bits is set changing STKPTR