We challenged the software engineer on why he declared a load of unused pins (PORTC pins) as inputs on the PIC16F1947 (they don’t even have internal pullups).
He came clean and admitted this was a "mistake". -And said he'd correct it.
The thing is, he did this before on us. We had to point it out to him that time aswell.
Once for several months he gave us code that would not work, (but he told us the code was fine and that our “noisy” hardware was making his code fail). …then we told him to bit-bash the incoming data instead of using the DALI libraries, and then the code worked….he had insisted that his code was fine and that our hardware was noisy and making his code go wrong. This turned out to be false, because when we got him to write his code in a simpler way, the product worked fine.
There have been too many “simple errors” with his codes for us. I believe he is deliberately trying to write “borderline” code which makes our products work sometimes and not others….ie….makes it fail intermittently.
Once we read his code and saw a correct line of code which correctly declared pins as either inputs or outputs….but then next to this line, he had a “commented out” line of code which had an incorrect declaration of the inputs and outputs…..next to this he had written “this is the code I will use for the actual product”…I am translating this from his own language in which it was written. When we asked him what he meant by this, he said that this was for a different version of the same PIC which would have needed the different declaration….however, no such “different version” exists.:-?
I believe he is deliberately trying to “throw a spanner in the works” and write dodgy code for us.:shock:
Please tell of ways in which a software engineer can write C code for PIC microcontrollers in order for them to work unreliably…then we can check through his code to see if he has done this. (eg declaring unused pins as inputs etc)