Silicon Chip Frequency Meter

Not that I recall, but I can't test it now because I've dropped it some time back, it flipped the power switch to "on", then broke the lever so you can't turn it off. When all is said and done, I found it with flat batteries and hadn't fixed it since. (yet)

From what I remember, there was _sometimes_ spurious characters, but not often, and only when switching from low/high in one direction (can't remember, and can't test at the moment).

On Thu, 06 Dec 2007 00:00:28 GMT, snipped-for-privacy@trap.ozemail.com.au (Andy Wood) put finger to keyboard and composed:

My DSE kit doesn't do this, but according to the errata there was a timing issue with certain displays that was "fixed" by the replacement of the 470pF capacitor on the E* input with a .0022uF capacitor. The symptom was a blank display.

- Franc Zabkar

Thanks Franc.

Interesting - they actually specifically mention the extra character before "HIGH" on the display. I located this on the SC web site under Notes and Errata:

"The 470pF capacitor between pin 6 of the LCD and ground may need to be larger in value for the display to operate. A value up to 2.2nF may be required if the display does not show any characters. This value of capacitance may cause the character preceding the word "HIGH" when the Resolution switch is pressed to have a couple of bars instead of a blank space. The normal frequency display when the switch is released will not show any abnormalities."

The capacitor they are referring to is connected between the LCD ENABLE pin and ground. The original article says that this capacitor is needed to "slow down the rise and fall times of the square wave from (the PIC), which are nominally too fast for the LCD module to handle ..."

I think what SC are saying is nominally bollocks. Heck, I have built my own projects with PICs driving those LCDs and never found it necessary to add a capacitor like that. The LCD specifications give no minimum rise/fall times for ENABLE, but do give a *maximum* (25ns), so too much capacitance there is likely to cause trouble.

History:

I bought one of the kits for this meter from DSE when they were having the kit fire sale earlier this year. That was actually at about the time the MK2 version was published in SC. When I got it assembled it did not work properly - the display would freeze. I did not think to go and look for errata published by SC.

I found that a finger on some of the tracks on the PCB could make the problem go away, but I could not find any bad connections. I located the source code for the PIC program on the SC web site and after some checking with a scope I suspected that code was getting stuck in a loop checking LCD 'busy'.

I tried a different LCD and it seemed to work OK. So far so good.

However, over time, when using the meter I found it would occasionally have some problems a bit like the original trouble. I did nothing about this until now when I decided to look at it again.

The LCD is used in four-bit mode (using only 4 data lines, so each byte to and from the LCD has to be transferred in two nybbles). I noticed that in the routine that checks if the LCD is busy, named BUS_CK, it does not always access two nybbles when reading the busy flag. I could not find anything to suggest that it is OK to do this, so I decided to try a modified version of the code.

I put back the original LCD and confirmed that it still would not work at all. I then changed the BUS_CK routine so that it always accesses two nybbles, and also threw in a couple of NOPs to make 100% sure the timing was right. I reprogrammed the PIC and after that the meter was working perfectly with the original LCD - except that I noticed the strange character on the display when changing the resolution. I took a look at the SC code and found a pretty obvious bug that would cause this problem (a stray call to the LCD-write routine, not in the area of code I had touched). I did not remember seeing that spurious character on the display before so that is why I was asking here.

I see that in the code for the Mk2 meter, the BUS_CK routine is completely different - it doesn't check the LCD busy at all, it is just a delay. The old code is actually still in there but cannot be executed. It seems they knew it was a problem area but perhaps did not know why.

When I get a chance I will remove that capacitor. I'm pretty sure that with the code changed it is not needed.

On Thu, 06 Dec 2007 21:42:19 GMT, snipped-for-privacy@ozemail.com.au (Andy Wood) put finger to keyboard and composed:

I'd appreciate a copy of your modded code, if that's OK.

- Franc Zabkar

All those parallel interface LCD modules are based on the Hitachi HD44780 chip or its clones. The HD44780 data sheet I've got only specifies a *maximum* Enable pulse rise and fall time of 25ns. There's no minimum. Enable pulse width (high) is 450ns minimum. Maybe that's what they're trying to stretch with that cap? Kinda bizarre way to do it. I've never had any problems driving LCD modules from micros (even PICs) in either 4 or 8 bit interface mode. Sounds like someone didn't have time to get right into understanding the timing requirements when they were designing it.

Bob

Just built the MK2 version (Jaycar) and it came with the .0022uF capacitor as an extra in case the display didn't work with the 470pF. Didn't need it in my kit.

Alan

Franc,

I have sent you an email with the modified code. Let me know if you don't receive it.

Andy Wood snipped-for-privacy@trap.ozemail.com.au

Another possibility is that they might be trying to read the data too soon after raising the enable line. With the rate the PIC is clocked at there, I don't think either of those would be a problem, but as I said, when I modified it I added a couple of NOPs just to be sure.

With the way it might read only one nybble instead of two, I'm a bit surprised that it works at all. What it looks like they could do is read the first half of the byte with the busy flag, and then turn around and decide to write a pair of nybbles to the instruction register. Perhaps when the LCD controller sees the write it is smart enough to reset its memory of high/low nybbles, and so gets back in sync. However I don't see it saying anything like in the specs so I wouldn't rely on it.

Exactly what I was thinking...

Andy Wood snipped-for-privacy@trap.ozemail.com.au

...

OK. I took the capacitor out and with the modified PIC code the meter is still working just fine.

Andy Wood snipped-for-privacy@trap.ozemail.com.au

Is it possible for you to post the code to a public 'net accessible area? If I'm the second who might be interested, I'm sure there would be others...

I haven't seen SC's code but from what I remember, when in the 4-bit mode, you have to read the upper *and* (irrelevant) lower nibble when checking the busy flag so as to keep the HD44780 in sync. Apart from all that, I reckon John Clarke deserves some kind of award and/or medal for turning out so many projects covering so much different electronics so regularly for all these years. The bloke's amazing!

Bob

On Sun, 09 Dec 2007 02:24:56 GMT, snipped-for-privacy@trap.ozemail.com.au (Andy Wood) put finger to keyboard and composed:

Got it. Thanks very much.

- Franc Zabkar

In a recent email, Andy indicated he didn't have provision for posting his code to the 'net for download, so I've done it here: This is Andy's revised code for the first incarnation of the frequency meter.

Through my home page look through the Utilities page, and scroll down to the bottom in the 'Electronics' heading. I know it seems out of place with all the cartography stuff, but I couldn't be bothered creating a new category for it.