Pitfalls related to PIC's and mikroPascal.

• Mixing bit and boolean logic.
  Example:

  if not((bit1=1) and bool_var) then ... // always evaluates true

  See Website of Janni, "mP PRO for PIC quirks and errors".
  Solution: Use Janni's "bool" function to convert "bits" into "booleans".
• Making arrays or strings too small, and fill them beyond their end. mP can not do do range checking while handling that type of variables. This type of errors will most probably result in ram data corruption.
  Possible solution for strings: use the "...X" procedures in StrngUtils to handle strings. Be aware of the "SizeOf" operator however when used on var parameters!
  See also the article RAMCorruption_SizeOf_StringConcat.pdf .
  
• Using a DS18B20: the "shift" to use on the temperature read from the Ds18B20 to obtain the integer (whole part) of the temperature is always 4, irrespective of the resolution the Ds18B20 is used in.
  However: the bits not meaningfull for a certain resolution should be ignored (e.g. bit 0 for a resolution less than 12 bits).
• Forgetting the pull-up resistor on the one-wire line (e.g. when using the DS18B20).
• Using a Bootloader: the configuration settings of the bootloader and those of the user code (firmware loaded by the bootloader) have to be equal. If they are not: the ones used are those from the bootloader.
• User libraries that are installed with the package manager should be defined in the right order in the processor's .mlk file. The correct order is needed because libraries that are "used" by others need to be defined "above" their "using" ones. The wrong order can occur if the "library dependancies" were not defined correctly or libraries were installed (usually manually) in a wrong order.
  This correct order of library definitions in the processor's .mlk file is only required if no source file is available or there are no "uses" statements in the source file.
  See the "User Libraries" tool to change the order of library definitions.
• Libraries, used without source file (so, only the .mcl file), should use an "external" declaration when accessing constants defined in project units, they should NOT have a "uses" clause of that project unit.
• Simple external constants can not be used in composed (array, string) external constants.
  e.g.

  const ValA:byte; external;
  const ArrayA: array[ValA] of byte; external;

  cannot be done. Instead use

  const ValA:byte; external;
  const ArrayA: array[10] of byte; external; // dummy size

  The correct size will be returned by e.g. SizeOf(ArrayA), no matter the dummy size.
• See here. ALWAYS put the SPI_Set_Active procedure call in the initialization whether you think you need it or not.
• Using renamed libraries (.mcl files). This will certainly cause "internal error"s when trying to link.
• Using {$UNDEFINE...} in stead of {$UNDEF...} (error in help, only $UNDEF works)
• Forgetting to wait a while (100 ms) after the harware uart init before using it.
• Assuming that global variables are initialized to zero on startup of the PIC's software. This is a mis-assumption: always initialise variables (global or local) before using their value!
• Assuming that working with PIC's is so easy that all projects will work right away without difficulties.
• Thinking that setting the clock speed in the IDE actually make the PIC run faster or slower.
  The clock speed in the IDE has to be set to the actual MPU speed of the PIC (defined by the crystal frequency and sometimes other settings) to make sure time dependant issues (like delays) are calculated correctly.
• A not connected MCLR (pic reset pin), while, in the configuration word(s), the MCLR is still enabled.
• Strings not terminated with a zero byte. Failing to do so results e.g. in a displayed string with "garbage" at the end. Tips
• Forgetting to set the configuration word(s) correctly, especially the oscillator configuration (which is not so simple for e.g. the P18F2550 family). Tips
• Forgetting to set the "clock speed" (= CPU speed, not necessarely crystal freq.) in the IDE correctly. This will result in troubles in all clock speed dependant code, like e.g. delays, u(s)art, etc...
• Forgetting to switch inputs to digital if they can also be used as analog ones. Solution: use All Digital from Yo2Lio .
• Forgetting about multiplexed pins (pins that can be digital in/out, but also used by e.g. internal pheripherals like Comparators or PWM).
• Forgetting to use pull-up or pull down resistors for e.g. push buttons. Tips
• Forgetting that some digital output pins are not push pull (= can both source and sink current), but "open drain" (= can only sink current).
• Forgetting to test and reset the interrupt flags in the interrupt service routine. Even better is also to test the interrupt enable bit together with the interrupt flag. Tips
• Forgetting to set the "Pheripheral Interrupt Enable" bit when interrupts from peripherals are wanted (e.g. a timer).
• Not waiting enough between "start temp conversion" and "read temp" with the DS1820. Time should be at least 750 millisecs (and not 120uS as in the mE example in the IDE help). In most examples with the waiting error things seem to go right because, eventually, the conversion will complete anyway (e.g. because there is a delay after showing the temp reading e.g. on an LCD), but all DS1820 temp readings done before the first completed conversion will be wrong. DS1820 Library/Example
• Forgetting about the internal eeprom write cycle: one should wait for 10 millisecs after a write before the next one, or a read operation.
• Forgetting the 100 nF decoupling capacitor close the the power supply pins of the PIC. If the pic hase more than one supply pin pair then each pair should have its 100 nF capacitor.
• Running into a watchdog timeout because of the usage of long unintended "delays" (e.g. in the "button" routine).
• Forgetting about the difference between a character and its ascii value, between a value and its string representation, etc. Important for devives or tools that expect characters (or strings) and not binary values (LCD, terminal software, ..). Tips, more tips
• Forgetting to connect (with a short wire) the 2 "GND" pins of the "on board IDC10 connector" when using PicFlash2. Only valid when one does not use a development board.
• Forgetting that, when reading from an I2c device, the last byte read should be not acknowledged. Tips .
• Forgetting about X24xx addresses. Tips
• Trying to call the same (not inline) routines from both outside and inside interrupts.
  This can, in some circumstances, give a "recursion not allowed" error.
  See however a workaround.
• Forgetting that ports (and not only their values) should be passed as "var" parameters to procedures/functions.
• Have more than one I2c device on the bus using the same I2c address range (e.g. PCF 8583P and X24Cxx devices).
• Forgetting to disable "Data Eeprom" in both "Program Options" and "Verify Options", and enable "Preserve Data (Eeprom)" in "Advanced Options" in the PicFlash software to preserve Eeprom data while writing the code to the PIC.
• Forgetting that mE's "Serial Ethernet Proto" board wants a supply voltage of 3.3V and not 5V. Tips
• Failing to understand the oscillator configurations of complex Pic's like the P18F2550 (PLL, USB, ...). Tips
• Forgetting to wait for a key release after a key press in case the action coupled to the key has to be executed only once. Tips
• Forgetting the pull-up resistors on the I2c lines. Tips .
• Forgetting to disable (relatively long) interrupts while sending/receiving via "Soft Uart", "Soft I2c" or "One Wire" (e.g. using the Ds1820).
  All three are very timing dependant.
• Forgetting that interrupt flags (...IF) are still set (if the corresponding event occurs of course) even in case the interrupt at hand is disabled.
• Forgetting to place text next to a case statement selection, see here and here.
• Forgetting that e.g. a byte can have no negative values. E.g. trying "for I := 0 to (strlen(StringVar) - 1) do ...", where I is a byte (or another non signed value), will do it 256 times if the StringVar was "empty", expression "(strlen(StringVar) - 1)" is -1 (or 255) in this case.
• Ignoring the warning "IRP bit must be set manually for indirect access to 'variable name' variable". This will lead to unpredictable software behaviour, because other ram space will be accessed that that reserved for "variable name". Solution
• Forgetting to check the necessary libraries in the library manager or adding them in the "uses" clause.
• Forgetting to add all "used" units together with the main file (the program file) to the project in the project manager.
• Trying to use the "SS" pin (SPI Slave Select) as digital input or output while using the SPI master mode.
  In the MSSP engine there is (at least in some PIC's like the P18F2620) a silicon problem, making an SS pin change destroy SPI data. Solution: set the SS pin (RA5 in the P18F2620) to output and never change its value.
  See here , here, and here and also SPI 18F4455 problem with SS pin in master mode (incredible) .
• Trying to use SPI with a non initialized SD-MMC card connected to it. The latter messes up the SPI connection with other SPI devices in the circuit. Always initialise (mmc_init) the SD-MMC card before trying to communicate with other SPI devices.
• PRO: If you want to use functions from the Math library then check the Trigon library in the library manager.
• PRO: Pointer conversion (from one pointer type to another) is not done automatically any more. It can be done with the "Dword" typecase for pointers into code, and the "Word" typecast for pointers into ram.
  From v3.80 onwards actual pointer typecasting must be used, the "Word" and "Dword" types (as described above) are not compatible any more with all pointer types. See also here.
• PRO: Pointer addition or substraction behaves like in Delphi now: If a pointer is declared to point to type, adding an integral value n to the pointer increments the pointer value by n * sizeof(type). If type has a size of 10 bytes, then adding 5 to a pointer to type advances the pointer 50 bytes in memory. Same principle for substraction. See also here.
• Ignoring the Read-Modify-Write problem when manipulating bits on an output port. See here.
• In present compiler version function results of type string cannot be used together with '+' concatenation, like in
  mystring := 'text' + string_function;

To be extended...

-------------------------------------------