Microcontroller controlled by pushbutton for LED flashlight

[(*steve*)]

Thanks. I'm pretty sure an approximate value was mentioned earlier. I'll go with that unless I get an update.

Whilst I didn't get time to build this up yesterday, I didn't because I noted an issue with the hysteresis of the voltage detector. I'm going to do some more calculations today to determine whether this will be a real problem.

 

[Arouse1973]

The voltage detectors I have on hand are not easily available, and I don't have any suitable open drain outputs, nevertheless I will test with what I have to see if the concept is sound.

The type of device I'm using is similar to these: http://ww1.microchip.com/downloads/en/DeviceDoc/20001434K.pdf

The important things will be:

1. It has the correct voltage range
2. It has an open drain output
3. It does not have an inbuilt delay
4. It does reset "active low"
5. It is available

There may be others cheaper than the one for which I have posted the datasheet, this is just to give you the idea.

Can someone verify the minimum input voltage (2.8V?) and the minimum voltage the PIC can reliably run at?

PIC10F200 is 2 Volts and the PIC10LF320 is 1.8 Volts up to 16 MHz then 2.5 Volts up to 20 MHz

Thanks
Adam

 

[Arouse1973]

So I got some code working on the 10F320. Much better PIC in my opinion. Sleep current isn't as low as I had hoped and running current is higher than hoped even running at 32 KHz it's 68 uA and sleep is around 12 uA. I need to look at this. The off time is around 2.4 ms (longest time before you notice flicker) and on time is approx. 64 ms. The next watchdog timeout was 128 ms, so I used 64 ms to keep cap size down.

Thanks
Adam

 

[hevans1944]

So I got some code working on the 10F320. Much better PIC in my opinion. Sleep current isn't as low as I had hoped and running current is higher than hoped even running at 32 KHz it's 68 uA and sleep is around 12 uA. I need to look at this. The off time is around 2.4 ms (longest time before you notice flicker) and on time is approx. 64 ms. The next watchdog timeout was 128 ms, so I used 64 ms to keep cap size down.

Your code looks pretty tight! Good job, Adam.

It does not appear to me that the WDT is used for anything except the 64 ms LED on-time. The off-time (used to charge the capacitor) appears to be a programmatic count-down, unless I am missing something reading the delay functions...

The 12 μA sleep current appears to be within published operating parameters, and with a 1 μF energy storage capacitor it is going to result in negligible loss of charge during a 64 ms on time. You can probably increase the WDT timeout to 128 ms without sacrificing too much drop in voltage on the capacitor.

When the PIC comes out of sleep after the WDT timeout, and you turn the LED off for about 2.4 ms, there is an abundant amount of current available to run the PIC and recharge the capacitor. The 68 μA consumed when the PIC is awake should not affect operation at all. See my post #237 for my calculations. Please verify the math in case I missed a decimal point or two or three...

Other than the WDT ending sleep mode by resuming execution where it left off, instead of resetting the PIC, I don't see anything in your latest code that can't be reverse-ported back to the PIC10F200T chip. Just have to add a bit-test to branch to the proper code section after the WDT barks and the PIC resets. However, I agree with you that the PIC10F(L)320 is a superior device. Now that my fear of soldering SOT-23 packages is somewhat abated, I think I will order a few to play with.

Hop

 

[BobK]

Now that my fear of soldering SOT-23 packages is somewhat abated, I think I will order a few to play with.
Hop

Welcome to the wonderful world of SMT! I was also afraid of it at first, but now that I have some experience I love it. A lot fewer holes to drill, and smaller boards. With drag soldering, I can actually solder a 44pin PIC faster than a 40 pin through hole one.

Bob

 

[Arouse1973]

Your code looks pretty tight! Good job, Adam.

It does not appear to me that the WDT is used for anything except the 64 ms LED on-time. The off-time (used to charge the capacitor) appears to be a programmatic count-down, unless I am missing something reading the delay functions...

The 12 μA sleep current appears to be within published operating parameters, and with a 1 μF energy storage capacitor it is going to result in negligible loss of charge during a 64 ms on time. You can probably increase the WDT timeout to 128 ms without sacrificing too much drop in voltage on the capacitor.

When the PIC comes out of sleep after the WDT timeout, and you turn the LED off for about 2.4 ms, there is an abundant amount of current available to run the PIC and recharge the capacitor. The 68 μA consumed when the PIC is awake should not affect operation at all. See my post #237 for my calculations. Please verify the math in case I missed a decimal point or two or three...

Other than the WDT ending sleep mode by resuming execution where it left off, instead of resetting the PIC, I don't see anything in your latest code that can't be reverse-ported back to the PIC10F200T chip. Just have to add a bit-test to branch to the proper code section after the WDT barks and the PIC resets. However, I agree with you that the PIC10F(L)320 is a superior device. Now that my fear of soldering SOT-23 packages is somewhat abated, I think I will order a few to play with.

Hop

Hi Hop

Ok so I got the circuit working by using it's own capacitance. The 1uF capacitor was no where near big enough, especially when the battery voltage reduced. The problem is the pull up resistor for the switch. When I had some initial issues with the first PIC10F200 I used an external pull up and not the weak pull ups internally.

I have a 47K resistor from supply to the switch input. You need to furnish this current also when the switch is pressed, but this value could be increased but I wouldn't want to go much higher than 100K because I read somewhere max pull up for a switch input was 47K. Maybe that was for some of the older PICs. This extra current could be for 500 ms because the LED has to follow the switch in order for the mode to change.

I then looked at the weak pull up spec and from 5.0 volts to 3.3 Volts they can vary from 16.5K to 300K. That's 300 uA to 25 uA if I just used weak pull ups. I personally always like to have an external pull up so I know where I am with this sort of thing.

I am using a 3.4 Volt battery so as to simulate a depleted cell this gives approx. 3.2 Volts to the PCB after the diode, this drops in operation to approx. 2.5 Volts, this could be due to the cap size and duration of cap charge time averaging out the voltage, I need to look at this in more detail. I ended up putting a 100 uF capacitor for the support, it's all I had at and increased the watchdog timer to 128 ms. The 100uF could be reduced if we change the pull up value but I ran out of time. I will see if I can do this tomorrow.

I also want to change how the code responds to switch presses because if you keep the switch pressed for longer than about a seconds it cycles back to the beginning.

That's not an issue but for now we have some code that I think should work to get things up and running. I have added some waveforms for people to see.

Cheers
Adam



Fig 1. Image showing PIC pin output when switch is pressed once.



Fig 2. Image showing supply dip when switch pressed once.



Fig 3. PIC output when running.



Fig 4. Supply ripple when running

 

[BobK]

Looking good!

The pullup should only use current while the button is pressed, so is it really a worry?

Bob

 

[Arouse1973]

Looking good!

The pullup should only use current while the button is pressed, so is it really a worry?

Bob

Hi Bob
The switch could be pressed for 500 ms so it's only this initial time during mode setting which would be the issue.
Cheers
Adam

 

[hevans1944]

Ouch! I completely forgot about the push button switch load! Especially when the LED is on and available current is at a premium.

I love your PicoScope screen captures! I guess I will have to bite the bullet and somehow squeeze the cost of one into my budget. A few weeks ago someone brought a high-end model PicoScope to the Thursday Night B-Road Meeting of the Dayton Amateur Radio Association (DARA). This weekly meeting starts at 7:00 PM and has been known to extend to the wee hours of the next morning. It is a bunch of hams who like to explore new technology. The latest seems to be SMDs. A bunch of them are gonna make a group order for a hot-air soldering station, but I think I will pass on that for now and put the money toward a PicoScope... or more likely, a cheap knock-off.

Is Figure 4 the supply running with the 100 μF capacitor? That's mighty small ripple!

The supply drop when the switch is pressed is humongous. Is the double-dip caused by switch contact bounce?

I will have to think more about this problem of the switch drawing so much current. At first blush, it seems to me that it doesn't have to have a pull-up all the time, just when you want to examine its state. How to do that when the PIC is sleeping (LED on)? Do you even have to do that during sleep? Or just when the PIC wakes up?

Maybe the program could remember the LED was turned on previously, and the next time you interrupt power by turning the LED off for a few milliseconds, turn on the internal pull-up and check the status of the switch? The rest of the time the switch input would remain in a high-impedance input state. I think once the switch is pressed to turn on the LED you can ignore it during the current sleep period and just look at again, when you re-charge the capacitor, to see if it is still pressed. This would extend the on time of the LED by at most one sleep period, wouldn't it? The LED would go off, and remain off, if the switch wasn't pressed at the end of the current sleep cycle. So, during the few milliseconds the capacitor is being re-charged, you could enable the internal pull-up and then (near the end of the capacitor re-charging process, to allow the stray capacity of an open switch to charge up through the internal pull-up) read the switch. If it is actuated, turn the LED back on and sleep. If it is not actuated, leave the LED off and sleep.

Adam, I am going to use your code on the PIC10F200 except I need to figure out a way to resume the program after a WDT reset. I am thinking a CALL $+1 followed by SLEEP will preserve where to return to. Then I check the TO and PD bits in the status register after a WDT reset occurs, and if both bits are cleared, do a RETLW to pop the stack into the program counter and resume where the program left off when it went to sleep.

I am still learning how to use the MPLAB X IDE, so I don't know how long it will take me to modify your code to test this idea. I spent a goodly amount of time yesterday trying to interpret the hex file that resulted from reading program memory in the PIC10F206 chip I have mounted on an 8-pin DIP chip carrier. I wanted to save (write down with pen and paper) the oscillator programming value you mentioned was stored at the end of the Flash program memory. There ought to be a way to load the hex dump into a disassembler program too, but I haven't found one yet. <sigh>

I just realized the last time I rolled any assembler code for a microprocessor was in the 1980s. Well, except for a few hundred bytes in the early 1990s for a PC-XT custom hardware interface.

 

[Arouse1973]

Ouch! I completely forgot about the push button switch load! Especially when the LED is on and available current is at a premium.

I love your PicoScope screen captures! I guess I will have to bite the bullet and somehow squeeze the cost of one into my budget. A few weeks ago someone brought a high-end model PicoScope to the Thursday Night B-Road Meeting of the Dayton Amateur Radio Association (DARA). This weekly meeting starts at 7:00 PM and has been known to extend to the wee hours of the next morning. It is a bunch of hams who like to explore new technology. The latest seems to be SMDs. A bunch of them are gonna make a group order for a hot-air soldering station, but I think I will pass on that for now and put the money toward a PicoScope... or more likely, a cheap knock-off.

Is Figure 4 the supply running with the 100 μF capacitor? That's mighty small ripple!

The supply drop when the switch is pressed is humongous. Is the double-dip caused by switch contact bounce?

I will have to think more about this problem of the switch drawing so much current. At first blush, it seems to me that it doesn't have to have a pull-up all the time, just when you want to examine its state. How to do that when the PIC is sleeping (LED on)? Do you even have to do that during sleep? Or just when the PIC wakes up?

Maybe the program could remember the LED was turned on previously, and the next time you interrupt power by turning the LED off for a few milliseconds, turn on the internal pull-up and check the status of the switch? The rest of the time the switch input would remain in a high-impedance input state. I think once the switch is pressed to turn on the LED you can ignore it during the current sleep period and just look at again, when you re-charge the capacitor, to see if it is still pressed. This would extend the on time of the LED by at most one sleep period, wouldn't it? The LED would go off, and remain off, if the switch wasn't pressed at the end of the current sleep cycle. So, during the few milliseconds the capacitor is being re-charged, you could enable the internal pull-up and then (near the end of the capacitor re-charging process, to allow the stray capacity of an open switch to charge up through the internal pull-up) read the switch. If it is actuated, turn the LED back on and sleep. If it is not actuated, leave the LED off and sleep.

Adam, I am going to use your code on the PIC10F200 except I need to figure out a way to resume the program after a WDT reset. I am thinking a CALL $+1 followed by SLEEP will preserve where to return to. Then I check the TO and PD bits in the status register after a WDT reset occurs, and if both bits are cleared, do a RETLW to pop the stack into the program counter and resume where the program left off when it went to sleep.

I am still learning how to use the MPLAB X IDE, so I don't know how long it will take me to modify your code to test this idea. I spent a goodly amount of time yesterday trying to interpret the hex file that resulted from reading program memory in the PIC10F206 chip I have mounted on an 8-pin DIP chip carrier. I wanted to save (write down with pen and paper) the oscillator programming value you mentioned was stored at the end of the Flash program memory. There ought to be a way to load the hex dump into a disassembler program too, but I haven't found one yet. <sigh>

I just realized the last time I rolled any assembler code for a microprocessor was in the 1980s. Well, except for a few hundred bytes in the early 1990s for a PC-XT custom hardware interface.

Hi Hop

Yes I like my PICO-SCOPE also. It's the basic 2206A and does have a arbitrary waveform generator that I haven't used yet.

"Is Figure 4 the supply running with the 100 μF capacitor? That's mighty small ripple!"
Yes correct.

"The supply drop when the switch is pressed is humongous. Is the double-dip caused by switch contact bounce?"
Yes correct

In running mode (on all the time) the switch is not pressed so no extra current will be drawn only the 25 nA or so for pin input current. It is only when the switch is pressed does this extra current happen. We can't avoid this because the port needs to change state and do something when the switch is pressed or held down for more than 500 ms at the start.

If we don't have a pull up or make the pin and input low or A/D port, the port pin will float and be in an indeterminate state which causes extra current to be drawn.

Yes we could make the switch an A/D pin initially then turn it into an input to check for switch presses.

I changed the pull up resistor to 330K, I know I said max 100K but hey lets live on the edge It's much better now and we might be able to get away with a say a 68uF

I'll look at your recommended code changes later Hop

Cheers
Adam

 

[Arouse1973]

Been working on a new PCB, using a new package so bit of a learning curve. I have designed it with the original PIC but it can be changed to another PIC if we can't get the 10F200 to work properly I have added a power connector also and the spare pin 2 for J1 I just connected to VDD. Would someone be so kind and give it a once over. I might get some made to have a play with later. I just need to work out how to generate the Gerber and I'll post that also.
Adam
Edit: Corrected missing trace

 

[Arouse1973]

Ouch! I completely forgot about the push button switch load! Especially when the LED is on and available current is at a premium.

I love your PicoScope screen captures! I guess I will have to bite the bullet and somehow squeeze the cost of one into my budget. A few weeks ago someone brought a high-end model PicoScope to the Thursday Night B-Road Meeting of the Dayton Amateur Radio Association (DARA). This weekly meeting starts at 7:00 PM and has been known to extend to the wee hours of the next morning. It is a bunch of hams who like to explore new technology. The latest seems to be SMDs. A bunch of them are gonna make a group order for a hot-air soldering station, but I think I will pass on that for now and put the money toward a PicoScope... or more likely, a cheap knock-off.

Is Figure 4 the supply running with the 100 μF capacitor? That's mighty small ripple!

The supply drop when the switch is pressed is humongous. Is the double-dip caused by switch contact bounce?

I will have to think more about this problem of the switch drawing so much current. At first blush, it seems to me that it doesn't have to have a pull-up all the time, just when you want to examine its state. How to do that when the PIC is sleeping (LED on)? Do you even have to do that during sleep? Or just when the PIC wakes up?

Maybe the program could remember the LED was turned on previously, and the next time you interrupt power by turning the LED off for a few milliseconds, turn on the internal pull-up and check the status of the switch? The rest of the time the switch input would remain in a high-impedance input state. I think once the switch is pressed to turn on the LED you can ignore it during the current sleep period and just look at again, when you re-charge the capacitor, to see if it is still pressed. This would extend the on time of the LED by at most one sleep period, wouldn't it? The LED would go off, and remain off, if the switch wasn't pressed at the end of the current sleep cycle. So, during the few milliseconds the capacitor is being re-charged, you could enable the internal pull-up and then (near the end of the capacitor re-charging process, to allow the stray capacity of an open switch to charge up through the internal pull-up) read the switch. If it is actuated, turn the LED back on and sleep. If it is not actuated, leave the LED off and sleep.

Adam, I am going to use your code on the PIC10F200 except I need to figure out a way to resume the program after a WDT reset. I am thinking a CALL $+1 followed by SLEEP will preserve where to return to. Then I check the TO and PD bits in the status register after a WDT reset occurs, and if both bits are cleared, do a RETLW to pop the stack into the program counter and resume where the program left off when it went to sleep.

I am still learning how to use the MPLAB X IDE, so I don't know how long it will take me to modify your code to test this idea. I spent a goodly amount of time yesterday trying to interpret the hex file that resulted from reading program memory in the PIC10F206 chip I have mounted on an 8-pin DIP chip carrier. I wanted to save (write down with pen and paper) the oscillator programming value you mentioned was stored at the end of the Flash program memory. There ought to be a way to load the hex dump into a disassembler program too, but I haven't found one yet. <sigh>

I just realized the last time I rolled any assembler code for a microprocessor was in the 1980s. Well, except for a few hundred bytes in the early 1990s for a PC-XT custom hardware interface.

Hi Hop
Been thinking about the option for jumping back to where you left off after sleep. Maybe an easier approach would be just to put a label after the sleep command you can then goto after you have checked the WDT bits. Another problem you have is that with two sleep commands one at the start and one in the LED on loop (charge cap) you would need to know which one reset you. You could the PCL value into a user defined register I suppose.
Cheers
Adam

 

[hevans1944]

Update on my progress with learning to use the MPLAB X IDE... turns out there is a disassembler built into it. I just need to learn how to use it if it turns out that I need it. My original objective was to read the oscillator calibration bits from the PIC10F206 I bought, so I could write those back when I programmed the PIC. So to that end, I used the PICkit 3 to read the program memory and display it (in Intel hex format) in a window on the MPLAB X IDE. So far, I haven't been able to interpret any part of that hex display into anything that resembles oscillator calibration bits. So, maybe I will just quit procrastinating and load up Adam's latest code and see what it does...

,,, If we don't have a pull up or make the pin and input low or A/D port, the port pin will float and be in an indeterminate state which causes extra current to be drawn....

I must have missed this somehow. Where in the datasheet does it say that a floating input will cause extra current to be drawn? If this is true, maybe the pin could be configured as an output and set low. Then when it's time to read the switch, set the pin to input with an internal pull-up, wait for the few picofarads of stray capacitance to charge up (if the switch isn't actuated), read the switch state and store the value read, then change the pin to output again and set it low.

Yes we could make the switch an A/D pin initially then turn it into an input to check for switch presses.

I don't think enabling the A/D function will reduce current.

I changed the pull up resistor to 330K, I know I said max 100K but hey lets live on the edge It's much better now and we might be able to get away with a say a 68uF

I think our goal should be to try to get away with no external pull-up, turning on the internal pull-up only when needed to read the switch status. I will try to conduct a few tests with my breadboard setup to see if this is possible.

Been working on a new PCB, using a new package so bit of a learning curve. I have designed it with the original PIC but it can be changed to another PIC if we can't get the 10F200 to work properly I have added a power connector also and the spare pin 2 for J1 I just connected to VDD. Would someone be so kind and give it a once over. I might get some made to have a play with later. I just need to work out how to generate the Gerber and I'll post that also.
Adam

Just looked over your lastest prototype board and circuit. Looks good, except for R1 = 10 kΩ will be an aggressive pull-up on GP3. How much current does R1 draw if GP3 is programmed as a digital input? Can you program GP3 as the /MCLR input and leave it without an external pull-up?

Hop

 

[Arouse1973]

Hi Hop

A floating port pin is not good for any micro. If not pulled up or down noise on the input can cause the pin to oscillate or be in an indeterminate state increasing PCB current. But if you set the pin to an output and high or low dependant on the design this will also work fine. I choose the a method dependant on the application

Analog input pins consume the least amount of current because the digital buffer is turned off. For the lowest possible current inputs should be left floating and set to analogue if the device supports this. But for most cases the pin input current is so low that a large value pull up will be fine.

The MCLR port pin typically draws 0.7 uA, but does have a maximum current of 5 uA when configured as a input with pull ups disabled. So we don’t want to go too low on this value because of the voltage drop across the pull up resistor.

I have never disabled MCLR on a PIC before so I am a bit apprehensive to do this. But welcome others to try this if they want to and see how it works out. You just don’t fit the resistors.

Regarding the oscillator calibration bit you read the memory in MPLABX by going to window and then program memory view and then program memory.

Cheers

Adam

 

[hevans1944]

Hello, Adam

I did know that CMOS logic isn't appreciative of open inputs. And so it seems that analog inputs need some finite impedance too. I learned years ago that there is always some bias current (could be very small) associated with analog inputs, so some sort of resistive path must be provided for the bias current. Back in the day (before FETs) it was not uncommon to have 10 Meg-ohm "bias return current" resistors at the analog differential inputs if high input impedance was required. And then you still had to trim out the differential bias current, which caused temperature sensitivity. Later analog amps were laser trimmed at the factory to zero the differential bias current, but that was a long time ago. Things are "all better" now.

I loaded your latest code into MPLAB X and am now in the process of converting it to PIC10F206 code. The .inc file for your PIC10F320 has all the wrong labels for the '206 of course, so I changed it to include the header for the '206 instead of the '320, which made all the '320 labels invalid. Also had to change the assembler directive __CONFIG. I went through your code changing PORTA to GPIO and commenting out the things that don't work (aren't implemented) on the '206, but it still hasn't assembled without error yet. <sigh> Another rung on the learning-curve ladder to climb, but at least I am having fun.

If you disable MCLR the PIC will still reset if you cycle power.

I was so FOS on my earlier conjecture about using CALL $+1 to jump around the following SLEEP instruction. What I wanted to do was push the PSR on the stack without actually branching, but... there is no PUSH PSR instruction! No pushes or pops implemented on these PICs.

I did notice your PIC pin definitions didn't match up with the board I received from @TenderTendon, so I corrected that too.

On your new board: there is no trace connecting the switch to pin 3 on the PIC.

More on this later...

Hop

 

[Arouse1973]

Hi Hop
I guessed you knew about floating ports, I wasn't trying to teach granny to suck eggs, apologies. I made a mistake on the pinouts yes sorry. It was late over here, no excuse though. The latest circuit has righted that so yes we need to change the code.
Adam

 

[Arouse1973]

Hello, Adam

I did know that CMOS logic isn't appreciative of open inputs. And so it seems that analog inputs need some finite impedance too. I learned years ago that there is always some bias current (could be very small) associated with analog inputs, so some sort of resistive path must be provided for the bias current. Back in the day (before FETs) it was not uncommon to have 10 Meg-ohm "bias return current" resistors at the analog differential inputs if high input impedance was required. And then you still had to trim out the differential bias current, which caused temperature sensitivity. Later analog amps were laser trimmed at the factory to zero the differential bias current, but that was a long time ago. Things are "all better" now.

I loaded your latest code into MPLAB X and am now in the process of converting it to PIC10F206 code. The .inc file for your PIC10F320 has all the wrong labels for the '206 of course, so I changed it to include the header for the '206 instead of the '320, which made all the '320 labels invalid. Also had to change the assembler directive __CONFIG. I went through your code changing PORTA to GPIO and commenting out the things that don't work (aren't implemented) on the '206, but it still hasn't assembled without error yet. <sigh> Another rung on the learning-curve ladder to climb, but at least I am having fun.

If you disable MCLR the PIC will still reset if you cycle power.

I was so FOS on my earlier conjecture about using CALL $+1 to jump around the following SLEEP instruction. What I wanted to do was push the PSR on the stack without actually branching, but... there is no PUSH PSR instruction! No pushes or pops implemented on these PICs.

I did notice your PIC pin definitions didn't match up with the board I received from @TenderTendon, so I corrected that too.

On your new board: there is no trace connecting the switch to pin 3 on the PIC.

More on this later...

Hop

Your right. I didnt notice the missing trace. I am using Dip Trace and have noticed nets being deleted when you move components, thats not very good. Maybe @Supercap2F has seen this and can help. Else I will email them.
Cheers
Adam

 

[Supercap2F]

Your right. I didnt notice the missing trace. I am using Dip Trace and have noticed nets being deleted when you move components, thats not very good. Maybe @Supercap2F has seen this and can help. Else I will email them.

No, haven't seen this issue when working with Diptrace. But on a some what related note: I have noticed that if you route a trace and then delete the trace the rat nest won't come back. But as a work around you can just go under File->Renew Design From Schematic->By Components Then in the pop up window select the schematic and click open, and the rats nest should reappear.

Just so you know, if @TenderTendon is going to be selling these you can't use the free version of Diptrace to design the schematics, because in their license it says you can only use it for non-profit designs. That's the only bad thing about Diptrace free!
Dan

 

[hevans1944]

Looks like there is room to run a trace from R2-1 to U1-3. But that's pr'ly the trace Dip Trace removed for you.

 

[hevans1944]

... Just so you know, if @TenderTendon is going to be selling these you can't use the free version of Diptrace to design the schematics, because in their license it says you can only use it for non-profit designs. ...

The final product will be a round disk, so there is plenty of time to find a work-around to the license problem... maybe even <gasp!> purchase the software. Adam is building a prototype board for test and evaluation. @TenderTendon can create a CAD file to mill one of his own, but that isn't at all necessary (or even desirable). I am sticking with the original CNC milled sample he sent me for my own meager efforts, plus a solderless breadboard for the PIC10F206 chips I have to test code and hardware on. If I can get it working on the breadboard, I will download to his board, being careful not to use '206 features not found on the '200 (extra memory and analog comparator).