Skip to main content

Anyone here a CCS fan?

Just picked up their PCHWD C complier. So far its a nice package. I am starting back into the world of micros after a 2 year break. So I figured I would start simple. I am making a meter board that I can use for all my toys.

It has 2 LED bar graphs (Left and Right) each with 19 LEDS. I am setting it up for dBFS scale but its is micro-based so it could be anything. I am using a huge 64 pin PIC (PIC16LF1947) with 53 I/O so I can do ANYTHING with it. I have 2 ADC set up to read a AC signals from the output of my mic preamp and compressors. I uses a simple voltage divider with a TVS clamp to ensure the pic only see 5 volts on its input.

I have a Push button hooked up to toggle between the viewing modes or scaling for that matter.

So far I thinking:
PEAK with max value linger
dBu etc...

Anyway the board is out to PCB shop and the code is mostly written. .

here is the schematic: DISPLAY R0.pdf

here is the 2 sided layout: DISPLAY PCB R0.pdf

I will post some c code when I get it debugged.

If Anyone else is playing CCS or pic's and C i would love to share ideas.

EDIT: Just to clear something up before hand. The schematic shows the LEDs in a VU type scale, but those are just net tags, the first iteration of the software is dBFS.


Boswell Mon, 07/26/2010 - 09:50

Looks a neat project, Link. I use the CCS compiler for all my PIC projects. You soon get the feel of what codes efficiently and what does not. The big thing to be aware of it how much bank switching goes on when accessing local variables, global variables and device registers. It pays to study the listing output from the compiler and then juggle the use of local versus global variables in procedures to minimize the bank swapping.

In your circuit, you will have to choose a TVS clamp with a low leakage so as not to cause inaccuracies in the digitized data, but there is quite a wide choice available. Are you deliberately rectifying the signal at the input of the PIC using the TVS diodes? If not, you could connect the PIC's analog inputs to the mid-point of a resistive divider from the power rail to ground with the signal from the TVS capacitatively coupled to it to get the full signal waveform into the PIC.

Link555 Wed, 09/22/2010 - 05:55

here is some quick photos

The code is now mostly working, I had to install a few updates from CCS, as they had not played with the PIC16F1947 yet....they don't have debug mode working yet but I can flash the chip at least now. So now I am working making the LED appear 'on' more solidly, what do you guys do average the reading and/or slow down the display speed?

Boswell Wed, 09/22/2010 - 07:05

For VU amd PPM displays, you need to follow the standard algorithms, which do include some averaging. However, if this is a level meter for digital inputs, you need to respond to and hold the input peaks so you can have a chance of seeing short excursions that could overload an ADC. I tend to like bar displays that leave a "max" LED on for a certain time while the others in the bar continue to show the current level. The "certain time" should be settable as either around a second or indefinite if you need to leave the unit and come back to see if there have been any overs.

Link555 Wed, 10/20/2010 - 15:53

So CCS now has debug mode working. I am still messing with the led smoothness. When I switch to my peak mode the leds flicker, like LM3914 without a rms converter in front of it. Which is essentially what I am doing, removing that in software, so I am not sure if I would use that mode..... I would like to write a real time averaging routine that does not require an array....any thoughts there?

Boswell Sat, 10/23/2010 - 07:04

Link555, post: 355269 wrote: .... I would like to write a real time averaging routine that does not require an array....any thoughts there?

I suggest low-pass filtering is the thing to use rather than true averaging. You could try a single-pole algorithm of the sort y' = x * a + y * (1 - a), where x is the new input sample, y the previous output and y' the new output. a is a constant in the range 0 to 1 that determines the position of the pole as a fraction of the sampling rate. This needs two multiplies, and probably multi-byte precision to make it work usefully. However, it's easy to simulate in QBASIC or some other friendly language, and you might be able to find values of a that give an acceptable time-constant while lending themselves to shift-and-add operations rather than full multiplies.