Today I messed around with the "f88 and got the code working to push updates to the three multiplexed displays in parallel. The controller, once completed, will be fitted to my dummy load. One A2D will read the voltage on the 1R shunt giving me current, the other will measure the input voltage. During the update process, the pic multiplies these two and gives a third readout in watts. These three figures are then pushed out to three shift registered with linked clocks and latches. Three four digit displays with just 5 IO.

I have finished off the door counter for work. We will see how helpful it is. I might put in the serial link today so that I can link it into the server.

Now to write a python daemon to monitor the clicks on the serial port!

I am currently working on a door counter. I have based it on the 16f84A (I bought a tube of them years ago before I worked out they weren't really that great). In keeping with the ancient PIC, I found ancient schmitt trigger to debounce. The TP4304. Its stamped '78. I scored a bunch of old CMOS from a closing electronics store.

http://www.datasheetarchive.com/dl/Datasheets-112/DSAP0044783.pdf

I have had a request to prepare a TG watchdog for installation inside a PC. To do this I am using the router to supply it power (as normal) and I have prepared a ribbon cable to go straight into the mainboards COM IDC header - rather than piggybacking ouside to a D9 socket and back in.

I also had the idea to use the TG watchdog as a means of powering down the box it lives in. Because it is powered externally to the server it lives it, it could reset or power down the system. I have some stuff I bought from mouser - 2 way inline SIL sockets and plugs. I'll have to post photos and part numbers. You could make a wedge cable to short the power or reset pins on the mainboard while leaving the button function intact.

I now have Hi-Tech C running under piklab. I'm glad that I tried it now.

After messing around for an evening or two with a stupid problem where bitwise OR assignments "|=" on PORTA and reading the value on PORTA fails, I decided that maybe SDCC was bugged. The OR would appear to work, but on closer inspection they actally zeroed the byte I was working on and only set the single bit that I was specifying. I installed MPLAB 8.73 with the Hi-Tech C compiler for 10/12/14/16 MCUs. There was trouble initially with wine as the picc.exe executable lived under "Program Files", So I moved the folder down to the home directory. This brought me a step closer as piklab verified the files exist - when it came to compile time piklab still tried to execute the linux executable rather than the .exe. I symlinked sdcc.exe to sdcc and libr.exe to libr and it now works fine.

Straight away I tried a compile (which failed) and then started the port from sdcc to picc. Once I had finished, the project built ok and I burned the hex to the pic (an 'f88). Lo and behold the same error occurred!

The code I used was originally an experiment with the adc which I wrote previously to try out SDCC. After combing the net I found a FAQ on the Hi-Tech website which described exactly my fault! I had a read of the FAQ and then checked out my code. Doh! I had remmed out the ANSEL declaration rather than implicitly setting it to 0. Facepalm.

Last night I decided to try SDCC again. It works much nicer than the last time I tried it. It also managed to make it work correctly with Piklab.

I have the USART and basic stuff running on a breadboarded TG watchdog.