One of my bugbears with cars I've driven is that their wiper system either don't t have an intermittent mode or if they do then they're fixed, i.e., the wiper sweeps the windshield approximately once every couple of seconds and there's no way of adjusting that time interval. Having an intermittent setting is better than none but having a variable intermittent mode is certainly much better. With a very light drizzle the windshield may need only need be wiped every 10 to 20 seconds, hence having a wiper control that has a user-adjustable wipe interval from one second to say one minute eliminates the hassle of having to turn off the wiper and then on again every now and then.
Some 8 years ago I designed and installed my first variable intermittent wiper control. It was a simple circuit based on the 555 timer configured as an astable multivibrator. It employed a potentiometer to allow adjustment of the wipe interval. The control circuit switched a relay which in turn switched the wiper motor on and off. It even had green and red LEDs indicators showing when the relay was on/off. By 2007 I had a preliminary microcontroller design but never got around to working on it.
Here's the Honda Civic's wiper stalk switch schematic. As indicated the relay contacts were inserted in series after cutting the parking position wire.
And here's the 555 circuit to implement the variable intermittent control. I used an aluminum electrolytic capacitor for the timing cap. But as is known aluminums are leaky. Using a tantalum would be better.
The circuit provides a momentary pulse to the wiper motor (less than a second) after which the motor latches--it powers itself through the parking position circuit--and then stops when it reaches the parking position where the wiper blades are back at the bottom of the windshield..
R3 is a 1Mohm potentiometer. Because of D1 (1N4148 signal diode) charging rate is much faster than discharge rate, charging only through R1. Theoretically, output high and low times are as follows:
Thigh = 0.693(R1)(C1) = 0.693(7.5Kohm)(100µF) = 0.52sec
Tlowmin = 0.693(R2 + R3min)(C1) = 0.693(15K + 0)(100µF) = 1.04sec
Tlowmax = 0.693(R2 + R3max)(C1) = 0.693(15K +1Mohm)(100µF) = 70.34sec
D3 is a flyback diode to dissipate the reverse emf developed across the relay coil when power to it is cut off.
An intermittent wiper control is relatively easy to design. The problem and headache is the cars themselves, specifically, figuring out which wires of the wiper switch go where and control what, and how sophisticated or primitive the installed wiper switch module is. A non-electronic wiper control as is found in the 90's Honda Civic is relatively straightforward. As can be seen above it only has mechanical switches and has very few settings--low speed, high speed, water spray, and momentary wipe (a spring loaded switch lets the driver turn on the wiper which turns off once the stalk is released).
Designing a control for a wiper system that already has an intermittent mode and employs electronics and which has a rear wiper-mist is a tad more difficult--because it takes more effort to analyze and reverse engineer the lot of switches and circuitry--something absolutely necessary because we don't want to fry the car's electronics and cause some major short circuit!
I've been meaning to install a variable intermittent control on the Toyota Innova for some time now but for fear of ruining the wiper system, or worse, zapping some other part of the electrical system--say, the very expensive car computer!--I've procrastinated even inspecting the wiper system to determine whether the project would be feasible. To add to the concerns, this car has an airbag on the steering wheel. Inadvertently triggering it was certainly on my mind. But last week, with trepidation, I finally dove right in.
To begin with I had to get to the wiper stalk's base--which was hidden within the steering column--to get to the wires leading in and out of it so as to be able to test them. As it turns out, removing the plastic covers surrounding the steering column was easy--the top and bottom halves simply snap onto each other and are held down on the steering with just two screws (one of which actually screws onto the detachable wiper switch module--strange I thought).
With the base of the stalk exposed two wire connectors became apparent. Pushing down on the retaining clips on the connectors permitted their removal from the wiper switch module. After some time studying the module I was able to remove it from the steering column--It had plastic "rails" onto which it slid in and one retaining clip was all that held it in place. Love that simple plug-in design. Here's a pic after I'd taken the wiper switch module off. The two white rectangular wire connectors dangling beneath the steering wheel are conspicuous. Those red and black wires and alligator clips are from my DMM.
Close up of the connectors:
And here are shots of the the module:
I was able to partially disassemble the module and here's how the sub units look:
Turning the parts over we have:
See all the copper "tracks" embedded in the plastic? They're thin copper inserts some of which lead to the headers and some to PCB on the other side. The yellow-greenish goo is lubricant for the sliding contacts.
And the headers/pins (into which the connectors plug) on the module:
Close up of the circuit board. There's one 3-terminal SOT device near the center of the board. No markings to identify it. Other devices are surface mount resistors. Values are readily discernible.
The PCB cannot be removed because there are some seven copper "posts" (embedded in the black plastic module) which are soldered onto the PCB. Here's how those copper posts look:
The PCB is at the top portion of the pics. They're overexposed in the images so you won't see the telltale green solder mask, just the edge of the phenolic? board.
In those two images notice the large black rectangular block. That's a relay although I could not see any markings on it. There's also at least one aluminum electrolytic capacitor in there. I could see the temperature rating but not its capacitance. The only way I'll be able to view all the components would be to desolder the posts. I'm not about to do that given my dodgy de/soldering skills. Maybe if I ever get a surplus unit I can do a teardown all the way.
In Part 2 I'll have the results of my electrical tests of the module.
Tuesday, June 7, 2011
Sunday, June 5, 2011
It's play time with conductive playdough
Recipe for conductive and insulating playdoughs. Their recipe is almost the same as the bbc's. For those who want to measure by weight like I do here's the newscientist's formula.
My main concern with the kid-safe conductive dough is that the high salt content will corrode wires, metals, and--Electra forbid--test instrument (multimeter) probes. According to Anne Marie Thomas a 1cm long dough with a diameter of 1cm has a resistance of 80ohms. Given the equation
R = ρ l/A
where
R = resistance in ohms
ρ = resistivity of the material
l = length of material
A = area
we can solve for ρ of this conductive playdough:
80ohms = ρ (0.01m) / [(0.01/2)^2(3.14)]
ρ = 0.63
I'm not the creative type so right now I can't think of any serious use for this stuff. The material isn't stable and will dry out and probably crumble, and its mechanical and electrical properties will change in a matter of weeks so the lifespan of circuits employing it will be quite limited.
My main concern with the kid-safe conductive dough is that the high salt content will corrode wires, metals, and--Electra forbid--test instrument (multimeter) probes. According to Anne Marie Thomas a 1cm long dough with a diameter of 1cm has a resistance of 80ohms. Given the equation
R = ρ l/A
where
R = resistance in ohms
ρ = resistivity of the material
l = length of material
A = area
we can solve for ρ of this conductive playdough:
80ohms = ρ (0.01m) / [(0.01/2)^2(3.14)]
ρ = 0.63
I'm not the creative type so right now I can't think of any serious use for this stuff. The material isn't stable and will dry out and probably crumble, and its mechanical and electrical properties will change in a matter of weeks so the lifespan of circuits employing it will be quite limited.
Friday, June 3, 2011
Bumped into a Hi-Tech C Compiler bug
Am developing a circuit using the PIC10F222. Since I don't want to code in assembly I chose to use Hi-Tech C Compiler for PIC 10-12-16 (freebie version) v9.81 within Microchip's MPLAB IDE (v.8.66). I'm still developing the software but when I compiled the very short initial code I got an error message saying that "TRIS" is an "undefined identifier." The offending line that tripped the compiler was "TRIS = 0b10". I couldn't understand why it would be flagged as an error since that's the correct syntax to initialize the TRISIO register (which is not accessible directly) according to Hi-Tech User Manual (DS51865B-page 53):
Given that last paragraph I changed TRIS to TRISIO, TRISA, TRISB, and TRISC. Still got the same error. I also changed the numerical values to decimal and hex. I even closed MPLAB and opened it again. None of these licked the problem. Finally since I have v9.80 installed I tried that to compile the program.
Lo and behold! The error message disappeared. When I opened the include file for the 10F22x for v.9.80 I found out that TRIS and TRISIO are defined therein, but they aren't in the 10F222 include file for v.9.81. Oddly though, while OPTION is defined in v.9.80 and isn't in v9.81, the latter nevertheless understood that command and correctly compiled it.
So there. That's a bug in version 9.81.
Having opened the include files for both versions, I was vexed to find out that there are a number of differences in the defines. For instance for the configuration bits, v9.80 lists the following:
while v9.81 has these:
None of the bit names are the same!
Since I'm using the ADC, the line "GO_nDONE = 1"--which is perfectly fine in v9.81--was flagged as an error in v9.80 because it only recognizes "GODONE." Now try compiling "GODONE = 1" in v9.81. What do you think will happen? You guessed it. You get a build fail.
For who knows what reason, Microchip not only demands we have a photographic memory to remember all those changing (or alternate) defines, it's also made it a hair-tearing ordeal to port firmware from one compiler version to the next. This is yet another reason I really would rather stick to mikroC if not for the fact that mikro doesn't support the baseline PICs and has a 2K code limit.
3.3.9.2 THE TRIS INSTRUCTIONS
Some PIC devices use a TRIS instruction to load the TRIS register. The <htc.h> header file will ensure a special definition for a C object called TRIS. PICC will automatically use the TRIS instruction when an appropriate processor is selected and the TRIS register is accessed.
For example, to make all the bits on the output port high impedance, the following code can be used.
TRIS = 0xFF;
This will load the appropriate value into the W register and then call the TRIS instruction.
Those PIC devices which have more than one output port may have definitions for objects: TRISA, TRISB and TRISC, depending on the exact number of ports available. This objects are used in the same manner as described above.
Given that last paragraph I changed TRIS to TRISIO, TRISA, TRISB, and TRISC. Still got the same error. I also changed the numerical values to decimal and hex. I even closed MPLAB and opened it again. None of these licked the problem. Finally since I have v9.80 installed I tried that to compile the program.
Lo and behold! The error message disappeared. When I opened the include file for the 10F22x for v.9.80 I found out that TRIS and TRISIO are defined therein, but they aren't in the 10F222 include file for v.9.81. Oddly though, while OPTION is defined in v.9.80 and isn't in v9.81, the latter nevertheless understood that command and correctly compiled it.
So there. That's a bug in version 9.81.
Having opened the include files for both versions, I was vexed to find out that there are a number of differences in the defines. For instance for the configuration bits, v9.80 lists the following:
// Configuration Mask Definitions /* Internal oscillator frequency select */ #define OSC_8MHZ 0xFFF // internal osc is 8MHz #define OSC_4MHZ 0xFFE // internal osc is 4MHz /* Master clear pullup enable */ #define MCPUEN 0xFFD // pullup enable #define MCPUDIS 0xFFF // pullup disable /*watchdog*/ #define WDTEN 0xFFF // watchdog timer enable #define WDTDIS 0xFFB // watchdog timer disable /* code protection */ #define PROTECT 0xFF7 // protect the program code #define UNPROTECT 0xFFF // do not protect the program code /* MCLR Pin function */ #define MCLREN 0xFFF // master clear reset enable #define MCLRDIS 0xFEF // master clear reset disable
while v9.81 has these:
// // Configuration mask definitions // // Config Register: CONFIG #define CONFIG 0x0FFF // Internal Oscillator Frequency Select bit // 8 MHz #define IOSCFS_8MHZ 0xFFFF // 4 MHz #define IOSCFS_4MHZ 0xFFFE // Master Clear Pull-up Enable bit // Pull-up disabled #define MCPU_OFF 0xFFFF // Pull-up enabled #define MCPU_ON 0xFFFD // Watchdog Timer Enable bit // WDT enabled #define WDT_ON 0xFFFF // WDT disabled #define WDT_OFF 0xFFFB // Code protection bit // Code protection off #define CP_OFF 0xFFFF // Code protection on #define CP_ON 0xFFF7 // GP3/MCLR Pin Function Select bit // GP3/MCLR pin function is MCLR #define MCLRE_ON 0xFFFF // GP3/MCLR pin function is digital I/O, MCLR internally tied to VDD #define MCLRE_OFF 0xFFEF
None of the bit names are the same!
Since I'm using the ADC, the line "GO_nDONE = 1"--which is perfectly fine in v9.81--was flagged as an error in v9.80 because it only recognizes "GODONE." Now try compiling "GODONE = 1" in v9.81. What do you think will happen? You guessed it. You get a build fail.
For who knows what reason, Microchip not only demands we have a photographic memory to remember all those changing (or alternate) defines, it's also made it a hair-tearing ordeal to port firmware from one compiler version to the next. This is yet another reason I really would rather stick to mikroC if not for the fact that mikro doesn't support the baseline PICs and has a 2K code limit.
Thursday, June 2, 2011
Bugs in the PIC12F1822 / 1840 datasheets
I mentioned a few days ago that there's something amiss in the datasheets for the PIC12F1822/16F1823 and PIC12F1840 regarding the DAC negative voltage source. I reported that problem to Microchip and today I received the following reply:
There is no negative Vref pin on the chips so that should've been the clincher for me.
In the PIC12F1822 and PIC16F1823 there is not a DACNSS bit. The drawing (Figure 17-1) and references to this are incorrect and the register bits are correct as published. The negative reference is always connected to Vss.
The PIC12F1840 DACCON0 is incorrect and bit ‘0’ should be unimplemented.
There is no negative Vref pin on the chips so that should've been the clincher for me.
Sunday, May 29, 2011
DAC using the FVR as voltage source
Continuing with the DAC tests over the last two days, I wanted to see the DAC using the internal fixed voltage reference instead of VDD. This would allow VDD to vary (with the condition that VDD > FVR output) without affecting the DAC operation. So I loaded the PIC18F1822 with the firmware below. Note that the internal oscillator frequency has been set to 31kHz to provide a delay between increment/decrement of DACCON1 value.
And here are the oscilloscope readings:
void InitRegisters() { PORTA = 0; ANSELA = 0; TRISA = 0; OSCCON = 0b1000; // run internal oscillator at 31kHz LF FVRCON = 0b10001000; // enable fixed voltage reference for DAC, set gain = 2 to give a ref volt of 2.048V } void main() { InitRegisters(); DACCON0 = 0b10101000; // DAC enabled, DAC output available on DACOUT pin, FVR as positive voltage source DACCON1 = 0x1F; while(1) { while (DACCON1-- >1); // go from DACCON1 = 31 to DACCON1 = 0 while (DACCON1++ < 30); // go from DACCON1 = 1 to DACCON1 = 31 } }
And here are the oscilloscope readings:
Checking the DAC unit on another PIC
Using the same hardware setup as in the PIC12F1822 DAC test I dropped a PIC16F1827 into the breadboard and checked how its DAC would perform, given that the 12F1822 flunked horribly. The data below says it all. The 1827's DAC performed as it should
The firmware was as follows:
After going over the firmware I used for the 1822 test I realized that I had inadvertently turned on the global weak pull-up--I cleared the WPUEN bit in OPTION_REG. Since all the bits of the individual weak pull-up register WPUA are high upon reset, the pull ups are then all enabled. This was the cause of the erroneous DAC output. So while pull ups may be enabled for other pins, if and when required, pull-up for RA0/DACOUT pin must be disabled if that pin will be used as DAC output.
After I burned the above firmware in the 1822, the DAC output instantly became as it ought to be, as the table below shows.
DACCON1 | VOUT measured (volts) | VOUT computed (volts) |
0x00 | 0.008 | 0 |
0x01 | 0.113 | 0.106 |
0x02 | 0.222 | 0.213 |
0x04 | 0.435 | 0.427 |
0x08 | 0.855 | 0.855 |
0x10 | 1.704 | 1.710 |
0x1F | 3.303 | 3.313 |
The firmware was as follows:
void InitRegisters()
{
PORTA = 0;
ANSELA = 0;
TRISA = 0;
}
void main()
{
InitRegisters();
DACCON0 = 0b10100000; // DAC enabled, DAC output available on DACOUT pin, Vdd as positive voltage source, Vss as negative voltage source
DACCON1 = 0x10; // change value of DACCON1 as required
while(1);
}
After going over the firmware I used for the 1822 test I realized that I had inadvertently turned on the global weak pull-up--I cleared the WPUEN bit in OPTION_REG. Since all the bits of the individual weak pull-up register WPUA are high upon reset, the pull ups are then all enabled. This was the cause of the erroneous DAC output. So while pull ups may be enabled for other pins, if and when required, pull-up for RA0/DACOUT pin must be disabled if that pin will be used as DAC output.
After I burned the above firmware in the 1822, the DAC output instantly became as it ought to be, as the table below shows.
DACCON1 | VOUT measured (volts) | VOUT computed (volts) |
0x00 | 0.028 | 0 |
0x01 | 0.134 | 0.106 |
0x02 | 0.239 | 0.213 |
0x04 | 0.451 | 0.427 |
0x08 | 0.874 | 0.855 |
0x10 | 1.717 | 1.710 |
0x1F | 3.292 | 3.313 |
Saturday, May 28, 2011
Test driving the PIC12F1822's DAC
Trying out the digital to analog converter (DAC) of the PIC12F1822. The most current datasheet (DS41413B) has bugs. The DAC block diagram (Fig.17-1) and description in Section 17 both indicate the existence of a negative voltage source (VSOURCE-) which is selectable via the DACNSS bit. But neither of the two DAC registers--DACCON0 and DACCON1--has the DACNSS bit.
On the other hand, in the datasheet (DS41441B) for the PIC12F1840 the DAC block diagram (Fig. 17-1) does not show DACNSS; however, register DACCON0 contains the DACNSS bit.
So does the DACNSS bit exist in the 1822 or not?
A search in the Microchip forum reveals that the DACNSS bit isn't available on the 12F1822 and that the negative voltage source defaults to VSS.
Okay, so the 1822 is referenced to ground. According to the datasheet, output voltage of the DAC is determined via the following equation:
VOUT = (VSOURCE+ - VSOURCE-)(DACCON1 / 25) + VSOURCE-
This means that if DACCON1 = 0, then VOUT = VSOURCE- = VSS.
But that isn't what I get while measuring the output at the DACOUT pin (enabled by setting the DACOE bit in DACCON0). Using the PICkit2 (with the ICSPDAT disconnected since that pin is also DACOUT) to power the 1822 and setting its VDD = 3.3 and with DACCON1 = 0 and DACPSS configured to use VDD, the Fluke 8842A DMM and Rigol DS1102E oscilloscope both measured DACOUT voltage at 332 to 333mV. It should read zero. 333mV is what we'd expect if DACCON1 is loaded with 0x03. Incidentally using the Fluke 8842A VDD was measured to be 3.42V.
With DACCON1 = 0x1F (decimal 31), VOUT = 3.32V. This is as expected as per the equation above. A summary of DACCON values tested are shown below.
Clearly, computed and measured values are planets apart.
Just to make sure the high impedance DACOUT wasn't being loaded, an op amp configured as a voltage follower (unity gain buffer) was used to buffer the DAC output, but the values obtained were the same as above.
Setting or clearing ANSELA has no effect on DACOUT output either.
I also tested the DAC "low power voltage state" by clearing DACEN, clearing DACLPS, and clearing DACCON1. Output at DACOUT was 313mV. It should be zero.
With DACCON0 cleared--i.e., DAC is completely disabled--and RA0/DACOUT pin configured as digital output and PORTA cleared, voltage reading was 2.5mV. So RA0 works as expected and voltage on this pin can in fact go down to practically zero.
So is there something very wrong with the DAC unit or have i missed some SFR setting?
On the other hand, in the datasheet (DS41441B) for the PIC12F1840 the DAC block diagram (Fig. 17-1) does not show DACNSS; however, register DACCON0 contains the DACNSS bit.
So does the DACNSS bit exist in the 1822 or not?
A search in the Microchip forum reveals that the DACNSS bit isn't available on the 12F1822 and that the negative voltage source defaults to VSS.
Okay, so the 1822 is referenced to ground. According to the datasheet, output voltage of the DAC is determined via the following equation:
VOUT = (VSOURCE+ - VSOURCE-)(DACCON1 / 25) + VSOURCE-
This means that if DACCON1 = 0, then VOUT = VSOURCE- = VSS.
But that isn't what I get while measuring the output at the DACOUT pin (enabled by setting the DACOE bit in DACCON0). Using the PICkit2 (with the ICSPDAT disconnected since that pin is also DACOUT) to power the 1822 and setting its VDD = 3.3 and with DACCON1 = 0 and DACPSS configured to use VDD, the Fluke 8842A DMM and Rigol DS1102E oscilloscope both measured DACOUT voltage at 332 to 333mV. It should read zero. 333mV is what we'd expect if DACCON1 is loaded with 0x03. Incidentally using the Fluke 8842A VDD was measured to be 3.42V.
With DACCON1 = 0x1F (decimal 31), VOUT = 3.32V. This is as expected as per the equation above. A summary of DACCON values tested are shown below.
DACCON1 | VOUT measured (volts) | VOUT computed (volts) |
0x00 | 0.333 | 0 |
0x01 | 0.760 | 0.106 |
0x02 | 1.074 | 0.213 |
0x03 | 1.328 | 0.320 |
0x04 | 1.533 | 0.427 |
0x08 | 2.093 | 0.855 |
0x10 | 2.640 | 1.710 |
0x1F | 3.320 | 3.313 |
Clearly, computed and measured values are planets apart.
Just to make sure the high impedance DACOUT wasn't being loaded, an op amp configured as a voltage follower (unity gain buffer) was used to buffer the DAC output, but the values obtained were the same as above.
Setting or clearing ANSELA has no effect on DACOUT output either.
I also tested the DAC "low power voltage state" by clearing DACEN, clearing DACLPS, and clearing DACCON1. Output at DACOUT was 313mV. It should be zero.
With DACCON0 cleared--i.e., DAC is completely disabled--and RA0/DACOUT pin configured as digital output and PORTA cleared, voltage reading was 2.5mV. So RA0 works as expected and voltage on this pin can in fact go down to practically zero.
So is there something very wrong with the DAC unit or have i missed some SFR setting?
Subscribe to:
Posts (Atom)