Prototyping boards / stripboards are hardly the easiest way to make printed circuit boards. Because of the fixed pads and tracks it's impossible to optimize the layout, minimize board size, and eliminate the use of jumper wires to electrically join the components. In fact it's this latter "dis-feature" that drives me up the wall. Cutting short lengths of wire and soldering them onto the board is the kind of exasperating work that has made me stay away from making PCBs as much as I can. Personally I find it a pain in every part of the body using these boards. And for all the work the outcome is hardly pretty.
So graduating to "real" PCBs has been a relief. The only reason I've procrastinated is that when I tried Eagle years ago I just couldn't comprehend how to use it. Turns out that Eagle isn't the most intuitive EDA software. Kicad was another candidate recently, not least because it's freeware. But it made me tear my hair out as well. Fortunately I found one that's easy--almost fun--to use. DesignSpark PCB is completely free (for now at least) and has no restrictions on board size, layers, and other features. According to tests performed by some individuals, DS came out the winner amongst various EDAs (including Eagle and Kicad). I don't know how rigorous the tests were and how objective their assessment is, but personally I did find it relatively easy to get started. With DS I was able to produce my first PCB within a couple of days.
Apparently DS is a "non-crippled and modified version of Easy-PC." Moreover, another Easy-PC derivative, PCB Artist, is almost exactly the same as DS. What's so cool about the PCB Artist is that I've found a good number of video and pdf tutorials on their page. And practically all of what you can learn about PCB Artist applies directly to DS. Meanwhile, DS tutorials can be found right on software itself under the Help menu. At least one of the PCB Artist pdf tutorial is almost exactly the same as that of DS.
Most of the work in setting up DS will be customizing the component/schematic/pcb libraries. Even with the extensive number of parts from various manufacturers already in the libraries I've found myself adding more and more components and editing the pads of existing items in the pcb library. I've also realized that I waste a not insignificant amount of time shifting from one library to another so I'm copying the most often used components to my own library. I will be editing the schematic library as well--a lot of the symbols are not at all pretty.
Wednesday, March 30, 2011
Monday, March 14, 2011
Four-way traffic light
Scoured some 20 toy and collectibles stores in search of a model/toy traffic light that I can hack and modify. Not a single one had. Unbelievable! So over the week I painstakingly constructed my own 4-way light out of 12 LEDs, a pseudo-lego piece, the tube of a spent marking pen, an AA battery case, and wires of course. Used cyanoacrylate glue, hot melt glue, and epoxy to hold them all together. Spray painted it black all over.
Not pretty at all. It looks worse than any signal light in Japan after it'd been felled and drowned by this week's Sendai tsunami. Good thing my nephew didn't mind its looks. Just hope it's strong enough to withstand the temblors from a 6-year old.
A Microchip PIC 12F1822 is the brains controlling the lights. To minimize power consumption its internal clock is set to just 125kHz. (This baby is capable of running at 32MHz!). Three AA batteries provide the juice. No current-limiting resistors are used for the LEDs. Measurements show they're not needed for VDD up to 4.5VDC. Only four MCU pins are used to switch the LEDs. Charlieplexing is employed to turn one LED in each of the four directions for 4milliseconds every 16 milliseconds (25% duty cycle). That's a frequency of around 62Hz--enough to fool the eye into not seeing the LEDs switching on and off that rapidly.
The original design was to power it off two AAs, but tests revealed that even without current limiting resistors the PIC could only deliver 5mA to the LEDs which have forward voltages of 1.6 to 1.8V. Considering the duty cycle is only 25% the average brightness would be quite low indeed. One option of course is to install very high brightness LEDs. I've searched RS Components and found various candidates. A possible drawback is that a number of these superbright LEDs have very high forward voltages, meaning their output will probably dramatically fall off as the batteries are depleted.
The circuit doesn't have an on/off (slide) switch. Instead the MCU goes to sleep 10 minutes after the last button press. When asleep pressing the button wakes it up and the light resumes operation in whatever it mode it was in when it dozed off.
When the lights are on the tactile switch/button allows the user to cycle between four modes:
1. Lights for opposite directions are on simultaneously. That is, when North-South is red, then South-North lights are red too and when NS is green SN is green too. Likewise with East-West and West East.
2. Light is green only in one direction at a time. This implies that for the direction that's green left-turning vehicles and those going straight can simultaneously go.
3. Four-way flashing yellow, 0.8 second on, 0.8 second off.
4. Four-way flashing red, 0.8 second on, 0.8 second off.
Just for fun I was tempted to add a four-way flashing green albeit at a much faster blink rate (say, 2 to 4 Hz). Would allow my nephews to have cars from all directions crashing into each other and getting a pile up. But I eventually scratched that idea--it's not a good way to train future drivers :)
Green stays on for 15 seconds, yellow for 2 seconds.
In modes 1 and 2, when after the light turns red, all directions will be red for a second. The rationale is that (in real life) any crazy driver beating the red light would be given enough time to cross the intersection without causing a tragedy.
When I gave the traffic light to John he critiqued the flashing mode saying one set should flashing yellow (eg. NS and SN) while the other (eg. EW and WE) should be flashing red. Actually I can't remember which lights are on in real four-way traffic lights during flashing mode. Googling shows that my nephew has a point. That's trivial enough to implement, given that the firmware uses a state machine implementation to charlieplex the lights.
The table on the right shows which lines (PORT pins) control which traffic light direction. The table on the left gives the TRIS and PORT status in order to light up LED Lx.
Here's the light at work:
Hoping to make a much more decent model the next time around.
Not pretty at all. It looks worse than any signal light in Japan after it'd been felled and drowned by this week's Sendai tsunami. Good thing my nephew didn't mind its looks. Just hope it's strong enough to withstand the temblors from a 6-year old.
A Microchip PIC 12F1822 is the brains controlling the lights. To minimize power consumption its internal clock is set to just 125kHz. (This baby is capable of running at 32MHz!). Three AA batteries provide the juice. No current-limiting resistors are used for the LEDs. Measurements show they're not needed for VDD up to 4.5VDC. Only four MCU pins are used to switch the LEDs. Charlieplexing is employed to turn one LED in each of the four directions for 4milliseconds every 16 milliseconds (25% duty cycle). That's a frequency of around 62Hz--enough to fool the eye into not seeing the LEDs switching on and off that rapidly.
The original design was to power it off two AAs, but tests revealed that even without current limiting resistors the PIC could only deliver 5mA to the LEDs which have forward voltages of 1.6 to 1.8V. Considering the duty cycle is only 25% the average brightness would be quite low indeed. One option of course is to install very high brightness LEDs. I've searched RS Components and found various candidates. A possible drawback is that a number of these superbright LEDs have very high forward voltages, meaning their output will probably dramatically fall off as the batteries are depleted.
The circuit doesn't have an on/off (slide) switch. Instead the MCU goes to sleep 10 minutes after the last button press. When asleep pressing the button wakes it up and the light resumes operation in whatever it mode it was in when it dozed off.
When the lights are on the tactile switch/button allows the user to cycle between four modes:
1. Lights for opposite directions are on simultaneously. That is, when North-South is red, then South-North lights are red too and when NS is green SN is green too. Likewise with East-West and West East.
2. Light is green only in one direction at a time. This implies that for the direction that's green left-turning vehicles and those going straight can simultaneously go.
3. Four-way flashing yellow, 0.8 second on, 0.8 second off.
4. Four-way flashing red, 0.8 second on, 0.8 second off.
Just for fun I was tempted to add a four-way flashing green albeit at a much faster blink rate (say, 2 to 4 Hz). Would allow my nephews to have cars from all directions crashing into each other and getting a pile up. But I eventually scratched that idea--it's not a good way to train future drivers :)
Green stays on for 15 seconds, yellow for 2 seconds.
In modes 1 and 2, when after the light turns red, all directions will be red for a second. The rationale is that (in real life) any crazy driver beating the red light would be given enough time to cross the intersection without causing a tragedy.
When I gave the traffic light to John he critiqued the flashing mode saying one set should flashing yellow (eg. NS and SN) while the other (eg. EW and WE) should be flashing red. Actually I can't remember which lights are on in real four-way traffic lights during flashing mode. Googling shows that my nephew has a point. That's trivial enough to implement, given that the firmware uses a state machine implementation to charlieplex the lights.
The table on the right shows which lines (PORT pins) control which traffic light direction. The table on the left gives the TRIS and PORT status in order to light up LED Lx.
Here's the light at work:
Hoping to make a much more decent model the next time around.
Wednesday, March 2, 2011
PIC 12F1822 current draw at different frequencies
Because the datasheet for the PIC 12F1822 lists the supply current for only a select number of internal oscillator frequencies I went and measured the current draw for all of them under various I/O settings.
The MCU was programmed and powered by a PICkit2 whose VDD was set to 5.0VDC when programming. It was set to either 5.0V or 3.0V when logging maximum, minimum and average current draw. The only thing connected to the MCU was the PICkit 2. The two were mated throughout the test. No resistors, capacitors, etc. were used. Ambient temperature during tests was 27° to 29° Celsius.
A Fluke 87V digital multimeter was set to read µA, with Min-Max feature enabled. The DMM was hooked up in series with the MCU's VSS and PICkit2's VSS. The meter was given between half a minute to a minute to gather data.
In the MCU configuration words, INTOSC with I/O function on CLKIN pin was selected. MCLRE, WDTE and PLLEN were disabled. Note that with the MCLR inoperative, RA3/MCLR pin is floating. Leaving an input floating increases current draw. In the tests below weak pull-ups were either enabled or disabled to record this difference. All peripherals (ADC, comparators, etc.) were left at their default settings, which I believe are off.
The various firmware used are provided below. C compiler employed was the mikroC Pro v4.60
A1.
A2.
B1.
B2.
C1.
C2.
Open this Google spreadsheet to see the test results. As can be clearly seen, the lowest power consumption is obtained with I/O pins set as output. The worst configuration as expected is that with floating inputs. It was discovered that having analog instead of digital inputs just slightly decreases current draw.
Below are screenshots of the pertinent table from the datasheet:
Compared to the datasheet, the results I obtained shows the 12F1822 (at least the chip I tested) performs better than specification, although I hardly duplicated Microchip's test conditions exactly.
According to the specs the LF version draws a maximum of 1.1µA during sleep @85°C, compared to the F version's 45µA. The astronomical difference probably implies the F version employs a low drop out voltage regulator to supply the MCU core with 3.6V (see the datasheets for the PIC 16F193X series for notes on the LDO).
The MCU was programmed and powered by a PICkit2 whose VDD was set to 5.0VDC when programming. It was set to either 5.0V or 3.0V when logging maximum, minimum and average current draw. The only thing connected to the MCU was the PICkit 2. The two were mated throughout the test. No resistors, capacitors, etc. were used. Ambient temperature during tests was 27° to 29° Celsius.
A Fluke 87V digital multimeter was set to read µA, with Min-Max feature enabled. The DMM was hooked up in series with the MCU's VSS and PICkit2's VSS. The meter was given between half a minute to a minute to gather data.
In the MCU configuration words, INTOSC with I/O function on CLKIN pin was selected. MCLRE, WDTE and PLLEN were disabled. Note that with the MCLR inoperative, RA3/MCLR pin is floating. Leaving an input floating increases current draw. In the tests below weak pull-ups were either enabled or disabled to record this difference. All peripherals (ADC, comparators, etc.) were left at their default settings, which I believe are off.
The various firmware used are provided below. C compiler employed was the mikroC Pro v4.60
A1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES // All I/O pins are all digital outputs in sinking current mode (grounded) // RA3/MCLR pin weak pull-up is enabled (MCU automatically disables pull ups for pins configured as output) void main() { PORTA = 0; TRISA = 0; ANSELA = 0; NOT_WPUEN_bit = 0; // global pull-up enable WPUA = 0XFF; // individual pull-up enable OSCCON = 0b0; // change OSCCON value to set various internal oscillator frequencies while(1) ; }
A2.
// FOR MEASURING SLEEP CURRENT // All I/O pins are all digital outputs in sinking current mode (grounded) // RA3/MCLR pin weak pull-up is enabled (MCU automatically disables pull ups for pins configured as output) void main() { PORTA = 0; TRISA = 0; ANSELA = 0; NOT_WPUEN_bit = 0; // global pull-up enable WPUA = 0XFF; // individual pull-up enable asm sleep while(1) ; }
B1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES // All I/O pins are by default analog inputs // All weak pull-ups are enabled void main() { NOT_WPUEN_bit = 0; // global pull-up enable WPUA = 0XFF; // individual pull-up enable OSCCON = 0b0; // change OSCCON value to set various internal oscillator frequencies while(1) ; }
B2.
// FOR MEASURING SLEEP CURRENT // All I/O pins are by default analog inputs // All weak pull-ups are enabled void main() { NOT_WPUEN_bit = 0; // global pull-up enable WPUA = 0XFF; // individual pull-up enable asm sleep while(1) ; }
C1.
// FOR MEASURING CURRENT AT VARIOUS INTERNAL OSCILLATOR FREQUENCIES // All I/O pins are by default analog inputs // All weak pull-ups are by default disabled void main() { OSCCON = 0b0; // change OSCCON value to set various internal oscillator frequencies while(1) ; }
C2.
// FOR MEASURING SLEEP CURRENT // All I/O pins are by default analog inputs // All weak pull-ups are by default disabled void main() { asm sleep while(1) ; }
Open this Google spreadsheet to see the test results. As can be clearly seen, the lowest power consumption is obtained with I/O pins set as output. The worst configuration as expected is that with floating inputs. It was discovered that having analog instead of digital inputs just slightly decreases current draw.
Below are screenshots of the pertinent table from the datasheet:
Compared to the datasheet, the results I obtained shows the 12F1822 (at least the chip I tested) performs better than specification, although I hardly duplicated Microchip's test conditions exactly.
According to the specs the LF version draws a maximum of 1.1µA during sleep @85°C, compared to the F version's 45µA. The astronomical difference probably implies the F version employs a low drop out voltage regulator to supply the MCU core with 3.6V (see the datasheets for the PIC 16F193X series for notes on the LDO).
Subscribe to:
Posts (Atom)