I have reverse engineered a cheap dual stage thermostat and written new firmware for it that is more suited for homebrewing purposes.
The thermostat has a PIC16F1828, a LED display, 4 buttons, 2 relays and temperature input using a thermistor that is read by the internal A/D.
I have added pretty much all the features I want (I have had to drop some functionality, as the PIC is tiny and especially RAM is very tight).
However, I have had issues during development and the few people who have helped me test have also experienced problems. What happens is that when I am testing a change, after uploading a new HEX, sometimes pretty much nothing works. It even seems that a HEX that works for me, won't work for someone else. I also get the feeling that (I can't remember for sure) even a HEX that worked before, could malfunction after this happens.
I need to add, that programming the chip is done with an Arduino UNO via a sketch I have designed myself, so while it is not unthinkable that there is a problem with programming the HEX data, it doesn't feel like that is the problem.
I know the PIC14 port is not mature, but it seems to have worked pretty well.
I'm not experienced when it comes to microchip products, but have worked with AVR's and have a pretty good idea of how microcontrollers work.
If there is anyone who have any insights to what the problem could be, I'd be very grateful.
Ideas I have so far is
* I'm using to much RAM, even though it seems to work flawlessly most of the time, that might just be luck
* There is some peripheral in the PIC that is not initialized when it should be. I only use 2 timers and one analogue input. I've read the datasheet for the PIC, and it seems most hardware I don't use, should not be enabled after reset.
* It could be a problem with programming, if just one increment address command fails, progmem will be corrupt. If this is the case, then the bug pretty much need to be dependent on the data being programmed, as I can use the same sketch to upload new HEX data until it somehow magically works again.
* There is something about the code that SDCC compiler generates that has some unforseen side effect.
The SDCC manual states that the PIC14 port "can work for simple code", while the code I wrote is probably not considered simple anymore, it seems to me that is an understatement. But it might be I'm experiencing issues from pressing the 16F1828 to the limit.
I do have problems understanding how much resources I'm using, I have during development run in to the compiler complaining about that program memory is full for a page. And also data memory being full. It does not anymore, as I have refactored, minimized and even dropped functionality. But can I count on that? The asm and lst files are pretty much greek to me, but at the end of the asm files an approximation of the number of instructions is shown, and that seems to be ok.
Also the MCU should reset on stack under/overflow, which it does not.