MCP3201 problems

[fratello]

Hi ! I tried to make an adapter for steering wheel audio controls, based on MCP3201 (since my previous tries based on PIC ADC failed, being inaccurate) . In Proteus it works fine, but in "real world" it doesn't work properly ...I can't figure out why !
Maybe someone can point me in the right direction ! Thanks in advance !

[HenrikOlsson]

What exactly does "doesn't work properly" mean?
What DOES it do and what do you expect it to do? Which PIC are you using and what does your hardware look like?

You've been around here long enough to know that a simple "doesn't work" is the wrong type of problem description. At least you did post the code so thumbs up for that ;-)

Give us something to work with. Does the PIC run at all? Does it run at the desired speed? Do you have control over the output pins? Is it a specific routine that doesn't work as expected. Basic stuff like that....

/Henrik.

[fratello]

Thanks for reply !
I attached iin my first post the Proteus simulation and the pbp file ... I used 16F676 for "driving" six resistors (for Sony players); MCP3201 must read the valiues of the steering wheel commands. But no matter what button I press, there are only two or three commands of six (Vol +, Source and seek+) and sometimes the same button does one of the three commands, randomly...

[HenrikOlsson]

Yes, I saw that but not everyone is fortunate to have Protues and the there are basically no comments in the code as to what the intention of it is nor for which processor it's intended. But now we know :-)

Do you have the serial display in the actual prototype as well? In that case you can determine if the values are being read correctly and the logic is at fault OR if the problem is either with the code reading the ADC or possibly with the hardware itself.

Speaking of hardware, I don't see a single decoupling capacitor in the schematic. Things like that may fly in simulation, seldom in real life.

The code seems to decode the the expected ADC reading values correctly but what does it do when a value does NOT match one of the cases? For example if adc_res is 700? I think you should set b_level to 0 at the start of the routine. Not that THAT neccesarily is the problem but still....

Also, I think you should "release" the CS pin as soon as you've done shifiting in the data.

/Henrik.

[fratello]

Thanks again !
I have 100 nF capacitors near to power pins of PIC and MCP ... I use a Sony player for tests ; I don't have a serial display.
As I said, my previous attempts (using PIC ADC) worked very fine in Proteus, worked very fine "on work table", but not so well on the car : sometimes the buttons wouldn't react properly (maybe because of automotive environment ?).
I used LM2931-CZ5 for power supply, 100 nF ceramic capacitors, even a 100 uH coil before the voltage regulator. The part of code which reads the values of ADC is the same in this code...

[tumbleweed]

There isn't 16 bits of data to read, so the adc_RES parameter will have to be adjusted after you shift in the data.
Even if you change it to not read 16-bits you should mask out the first few bits read since they are undefined.

See section 6.1 in the MCP3201 datasheet.

[Jerson]

It is a long time since I used the MCP3201, so I am not current with the information. I will suggest the following change to be made


if b_level=last_b_level then
b_cnt=b_cnt+1
pauseus 500
if b_cnt > 10 then
TRISc = %11111111
gosub comenzi
ENDIF
else
b_cnt = 0
endif


This change will ensure that only 10 stable level readings will be counted. Any fluctuation will be ignored.

The ADC way for reading keys is not the ideal way.

Regards
Jerson

[fratello]

Thanks for suport !
@Tumbleweed : I used code from this post : http://www.picbasic.co.uk/forum/showthread.php?t=18495&p=123207#post123207
@Jerson : Tried already ...no improvement !

@ __config _INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_ON & _MCLRE_ON
DEFINE OSC 4

CMCON = 7
ADCON0 = 0
ADCON1 = 0
ANSEL = 0
VRCON = 0

TRISA = %00000100
PORTA = %00000000
TRISC = %11111111
PORTC = %00000000

MI VAR PORTA.1
SCK VAR PORTA.2
CSN VAR PORTA.0


adc_RES var Word


last_b_level var byte
b_level var byte
b_cnt var byte
b_act var byte

CSN = 1

main:
TRISC = %11111111
CSN = 0
SHIFTIn MI, SCK, 4, [adc_RES\16]
CSN = 1
if adc_RES < 2600 then

IF adc_RES > 300 AND adc_RES < 320 THEN b_level=1
IF adc_RES > 560 AND adc_RES < 590 THEN b_level=2
IF adc_RES > 890 AND adc_RES < 910 THEN b_level=3
IF adc_RES > 1280 AND adc_RES < 1300 THEN b_level=4
IF adc_RES > 1790 AND adc_RES < 1820 THEN b_level=5
IF adc_RES > 2420 AND adc_RES < 2440 THEN b_level=6





if b_level=last_b_level then
b_cnt=b_cnt+1
pauseus 500
if b_cnt > 10 then
TRISc = %11111111
gosub comenzi
else
b_cnt= 0
endif
endif

last_b_level=b_level
serout2 porta.5, 84, [ dec adc_RES, " ", dec b_level, " ", dec b_cnt, 13] ; to see ADC values
endif
pauseus 100
goto main

;================================================= ===========================

comenzi:

IF b_level=1 THEN gosub VoldN
IF b_level=2 THEN gosub Volup
IF b_level=3 THEN gosub Mute
IF b_level=4 THEN gosub SeekUp
IF b_level=5 THEN gosub SeekDn
IF b_level=6 THEN gosub Source
last_b_level=0
b_cnt=0
Return
;================================================= ===========================

voldn:
TRISC = %11111011
pause 100
TRISC = %11111111
return

volup:
TRISC = %11111101
pause 100
TRISC = %11111111
return

seekup:
TRISC = %11011111
pause 250
TRISC = %11111111
return

seekdn:
TRISC = %11111110
pause 250
TRISC = %11111111
return

source:
TRISC = %11110111
pause 200
TRISC = %11111111
return

mute:
TRISC = %11101111
pause 200
TRISC = %11111111
return

END

[tumbleweed]

You missed the following from that post...

Sensor = (Sensor & $FFF) * 5000
The AND with $FFF masks out the unused bits. The multiply by 5000 is to scale it to 5V, so you can skip that part.

Look at the diagram in post #4 of that thread and you'll see that the first few bits of data are invalid. To be honest it looks to me like even that code from Darrel isn't quite right since it also shows getting a duplicate B1 bit into the LSB. I would think the result should be shifted right by 1 before doing the AND.

I don't think your original problem with the pic ADC had anything to do with the internal adc being inaccurate so none of this may help much. You say it worked fine until you put it into the vehicle. That should be a clue.

[fratello]

Despite all the modification, the "adapter" still work foolish ... No change to the initial code.
...
"You say it worked fine until you put it into the vehicle. That should be a clue. "
I think so ! But I have not been able to identify and eliminate the cause so far.That's why I've been thinking about using this MCP ....

[tumbleweed]

Do the raw ADC readings out the serial port make sense? I'd concentrate on getting those right first.

[mark_s]

It would be a lot easier to use another pic with 3 extra I/O pins. Then your 6 push buttons would be reliable. But if you are minimalist and want a challenge go for it.

[fratello]

@tumbleweed : I don't understand what you mean ...
@Mark's : It's impossible another approach ! The steering wheel commands don't allow ...

[midali]

Hello Fratello,

Sounds like a hardware issue. I worked with LM2931 and i had some strange problems because I used a lower capacitance on output. Connect a 100uF (0,1uF is too low) near the stab pack on output line. "On work table" all are ok because may be you use a power supply who have a big capacitance. Also, when pic works with signals its necessary to decoupling with 10uF capacitance.

[fratello]

Thanks ....but I have already FULL decoupling...8538

[AvionicsMaster1]

Just curious if the symptoms change when the RPM is varied?

[fratello]

Nope :) ! No change !