Binary input Hex dispaly (7 segment LED)?

[dalmation]

Thanks.
Definitely making good progress- but The amount of resistors I'm having to add is worrying me a bit.

I have been designing the PCB whilst experimenting and the biggest problem is space for the tracks to be routed. The exrta 32 pulldown resistors arent gonna help me much in that respect. The external power supply in a bit of an inconvenience as well- but I will get it up and running.

The problem with the PCB is that it is only 12x4cm. I have designed with SOIC pic chips to save some room but its still very tight.
If the PIC chip had a better pinout (RA0-7 on one side, RB0-7 on the other), it would fit in perfectly with the layout.

Even with a 4 layer board- I might have to remove the display and place it on top using headers to stand it off-hopefully not though.

I'm not moaning- just thinking ahead

I'm over the moon that its working, though cant wait to tweak it to perfection.

-Dalmation.

 

[ericgibbs]

hi,
You could use SMT resistors, if space is tight or SIL resistors [the individual resistor version]

 

[dalmation]

Everythings been designed with surface mount resistors (size 0805)- but its still incredibly tight. The display is through hole and I made the transistors through hole (they actually took up less space then smt).

The SSOP version of the pic might be a better option and I can solder them no probs- just takes me a bit longer.

I got a sample of the QFN package- NO CHANCE!!

Very cute little package and the pinout is almost perfect- but the whole thing is 6x6mm with 28 solder pads (underneath). Beyond me I'm afraid.

Like I said though- I've got it working- I'm happy- the final design will just take a wee bit of time.

-DAlmation.

 

[dalmation]

just a wee update...

Digit1 was showing a slight ghost image of digit2. Turned out it is caused by a little leakage (1.2mA) coming through from the 2nd transistor.

I was using a 1K resistor on the base of both transistors.
I fixed the problem by usink 1K on transistor 1 and 3.3K on transistor 2. There is now no ghost image, and only 0.03mA difference in current on the 2 displays.

The other problem I am having, is some slight interference- the display is good but every so often it misreads for a milisecond. The true reading is obvious, but if it continues (I'm hoping its due to oversized, undershielded prototype), I might need a firmware update.

Would it be possible for the display to update less often, but update with the most common result (ie- if it read over a period of time CCCCDCCDCCCC, it would ignore the D and just read out C?

I'm not asking for someone to do that for me- just want to know it's possible before making a proper PCB.

Thanks.

-DAlmation.

 

[ericgibbs]

Digit1 was showing a slight ghost image of digit2. Turned out it is caused by a little leakage (1.2mA) coming through from the 2nd transistor.

I was using a 1K resistor on the base of both transistors.
I fixed the problem by usink 1K on transistor 1 and 3.3K on transistor 2. There is now no ghost image, and only 0.03mA difference in current on the 2 displays.
I will add that to my drawing, I expect Mike do the same.
Thanks for the feeadback.

The other problem I am having, is some slight interference- the display is good but every so often it misreads for a milisecond. The true reading is obvious, but if it continues (I'm hoping its due to oversized, undershielded prototype), I might need a firmware update.
It could be em noise as you suspect, keep us posted.

Would it be possible for the display to update less often, but update with the most common result (ie- if it read over a period of time CCCCDCCDCCCC, it would ignore the D and just read out C?
If the program only refreshed the digits that have changed since the last update, wouldn't the 'unrefreshed digits go blank or very dim?

I'm not asking for someone to do that for me- just want to know it's possible before making a proper PCB.

hi,
Noting your earlier post about the number of segment resistors, in the past I have fixed the SM resistors under the 7seg LED sockets, to give extra pcb space.

The advantage with using digit pairs is that the duty cycle is 50%/digit, if you mux'ed all 8, you would get a 12.5%/digit and that would make them 'dim' and there is a limit on how much current the PIC port pins can source.

 

[dalmation]

Would it be possible for the display to update less often, but update with the most common result (ie- if it read over a period of time CCCCDCCDCCCC, it would ignore the D and just read out C?

If the program only refreshed the digits that have changed since the last update, wouldn't the 'unrefreshed digits go blank or very dim?
.

With the way I use this circuit, the display will only change values every 10 seconds or so, but must always display the value.

What I meant was...

For talking sake, lets assume the pic makes 10 readings/displays per second.
Currently, the display is in real time to each reading.

What I am proposing is that for example the firmware does this...(time intervals just for discussions sake)

-Take 10 readings (over 1 second)- remember them- display nothing
-Display most common value from reading1, 10 times whilst taking the next 10 readings.
-Update display with new most common reading 10 times.


So basically the display is 10 readings behind the 'reader'. The processor will basically be removing readings that are different from the majority.

The display will always be displaying, but will not have the ability to show momentary 'flicker values'


-Would make a nice difference to display quality- but I dont know if it can be programmed.

-Dalmation.

 

[dalmation]

Just a wee question... to use the internal low power oscillator- I would need to add an external crystal?

Also just to confirm- this isnt possible due to no pins being available to accomodate the crystal.

I'm pretty sure thats right- can anyone confirm?

Thanks

 

[ericgibbs]

Just a wee question... to use the internal low power oscillator- I would need to add an external crystal?

Also just to confirm- this isnt possible due to no pins being available to accomodate the crystal.

I'm pretty sure thats right- can anyone confirm?

Thanks

hi,
Look at datasheet 4.2.2.6 INTOSC, config bit 3 for 48KHz osc not 4MHz
No external xtal. OK

EDIT: Remember to edit the programs interdigit delays, Bill's written it for 4MHz.

 

[dalmation]

Okay

I will figure out how to adjust the timings- I can manage that myself.

I'll turn the clock down and then I am going to switch off the BROWNOUT RESET. Thats the monster thats been switching the chip off at 4.0V. It means my chip might still run at 3.3V. That would be FANTASTIC!!!

I'll try to figure it all out tonight.

Thanks guys.

-Dal.

 

[dalmation]

Superb!! Disabled the Brownout Reset option, and the circuit works fine at 3.3V.

I havent even adjusted any of the resistors for the lower voltage yet.

The interference should be less too now cos the 3.3V supply is very smooth and well regulated.

I'm well happy

-DAl.

 

[Mike - K8LH]

Fixed the 'C' character error and updated the v1 and v2 program files (in earlier post). The problem found in the v2 program (the interrupt version) was PORTB never getting set to output (oops! sorry!).

I wonder if your changing digit problem is related to that "strobe" pin? Could it be a "data valid" signal of some sort?

Also wonder if your PCB layout problem couldn't be solved by installing the PIC devices on one side of the board right in the middle of the LED footprint with the LEDs installed into headers on the other side of the board?

Mike

 

[Mike - K8LH]

Averaging or filtering your BCD input data can be tricky. Fortunately, using a 16 or a 256 step size (filter width) translates nicely into a simple and tight algorithm and code.

For example, here's a variation of Andrew Warren's 8-bit 256-step averaging filter example. Since an 8 bit number multiplied 256 times fits perfectly in two 8 bit bytes we can manipulate the average as a 16 bit number and conveniently end up with the AvgHi variable containing the integer "average" of the last 256 (8 bit) samples;

;
;  avg = (avg * 256 - avg + new) / 256
;
        movf    AvgHi,W         ;                           |B0
        subwf   AvgLo,W         ; W = avglo - avghi         |B0
        skpc                    ; borrow? no, skip, else    |B0
        decf    AvgHi,F         ; bump avghi                |B0
        addwf   New,W           ; add 'new' sample          |B0
        movwf   AvgLo           ; update avglo              |B0
        skpnc                   ; carry? no, skip, else     |B0
        incf    AvgHi,F         ; bump avghi                |B0

It takes 256 samples of a "new" value before that value shows up in the "average" output. In our case using 8 msec sample intervals, it would take approximately 2 seconds for the "new" filtered value to show up on the display. We could also increase the sampling rate if we need a faster update.

I modified the version 1 software and added a pair of these 256 step averaging filters and attached it as version 3 software below.

Have fun. Mike

<corrected error in v3 listing, 02-Oct-07>

 

[dalmation]

Thanks- I'll try it tomorrow.

I mentioned earlier that I ahd to add pull down resistors to the inputs...

Since I've moved to 3.3V supply- these are no longer needed. The problem must have been the pic having 5V supply and dealing with cmos logic from a 3.3V circuit.

I'm still working on the prototype PCB- its easy using 4 layers- but I'm gonna struggle ahead for a 2 layer to save cost if I can.

The interference is less random now (every few seconds)- I'm gonna try your new firmware and let you know- I'm also gonna add an electrolytic cap to the supply pins.

I'll get back to you soon.

Thanks again.

-DAlmation.

 

[Mike - K8LH]

I mentioned earlier that I ahd to add pull down resistors to the inputs...

Since I've moved to 3.3V supply- these are no longer needed. The problem must have been the pic having 5V supply and dealing with cmos logic from a 3.3V circuit.

So no need for those 32 pull down resistors. That's great news. I don't think any of us realized you were dealing with 3v signal levels.

 

[dalmation]

Its working great now anyways.
Havent tried the new firmware yet- I'll let you know tonight.

-Dal.

 

[Mike - K8LH]

Please reload the v3 program listing as I corrected an error... Sorry!!!

 

[dalmation]

Hello again,
Still havent tried the new firmware- I've been spending all my spare time designing the PCB. Its hard work fitting all that stuff on a tiny board!
Just about ready to make it, though.

I've been buying in the components and I have a wee question,

A supplier has offered me a cheaper alternative to the 16F628A- he has some unwanted 16F627A that I can have for almost half the price.

I looked up the spec, and the 627A has only 1.5Kbytes where the 628A has 3.5Kbytes. For these short programs that would be okay- wouldnt it?
It was the only difference I could find.

What would be involved in making the programs run on the 627A? - it would save a fair bit of cash.

Thanks again

-Dal.

 

[ericgibbs]

hi,
Looked at 627A spec sheet, its only got 1024bytes flash memory, IIRC the program isnt that big, everything looks the same as the 628A.

 

[dalmation]

Nice one, I'll give it a go.

In terms of the ASM files- would I need to do anything other than change the chip name at the top?

Sorry- that probably sounds really pathetic... I do have pic training materials that I plan to study (lots)- just havent yet

-DAl.

 

[Pommie]

As you suspected, just change the device under the "configure\select device" menu and change the include filename and device type at the top of the file.

Mike.