Wednesday, May 30, 2012

Bench Power Supply - Progress Update

Here's a little video I shot of my power supply in action. I think it is very close to being workable. I have a bunch of placeholder parts, since I'm holding off on placing an order for final parts until I do more testing.

One thing I've been working on recently is the current-limit-mode indicator LED's. It's a little but harder of a problem than I thought it would be. My current limit comes from Q1 in the schematic. As the current flowing through R1 rises, it causes the voltage on the "+" input of the U2 op-amp to eventually exceed the ISET voltage. This drives U2's output high which in effect ties U4's output close to ground. My idea was to connect the "+" side of U4 to a spare input on my IO expander, and sample it's value in code. My initial thoughts were that a low value indicates that the circuit is in "current limit" mode. It turns out there are numerous reasons that this wont work. The face palm moment was realizing a low VSET value will also trigger the current limit logic regardless of the actual current! The other major problem was that I was using a digital input to estimate what is really an analog voltage.

Anyways here's the video:

Friday, May 18, 2012

Bench Power Supply - Point of no return

Just  a quick(not really) update.

I've got a lot of the code side of things worked out. I had a lot of "fun" doing software debouncing for my rotary encoders. After hooking up a logic analyzer, I realized that using the I2C IO expander for the encoders was not going to work. The I2C chip I'm using, an MCP23018, has a couple interrupt lines, one of which I used to alert my ATmega that the expander needed attention. Since the expander is an I2C "slave", this is the only way it can initiate communication with the microcontroller. An interrupt handler in my code would set a flag and exit. When my "main update loop" got around to checking that flag it would then issue a series of I2C commands to query the expander for the encoder line change that triggered the original interrupt. All of this turned out to be way too slow to process encoder input. The main culprit was the fact that it depended on the main code loop getting around to checking that flag. From my logic captures, I could see that encoder edge transitions could happen sometimes 5ms apart. When there was a lot going on, such as heavy LCD updates, my main loop could sometimes take 20-30ms to complete one loop. Ouch.

You can't easily, if at all do I2C in an interrupt handler, you can not be sure of what state the I2C line is in when the interrupt fires. In the end, rather than figuring out a way to do I2C in an interrupt, or doing more flag checking (which would have been a hack, sometimes most of the CPU time is spent deep in the LCD bit bang code), the simpler solution was to move the encoders to the AVR itself. I had to give up UART functionality that I was planning, since I'm tight on allocated pins, but I was leaning toward doign that anyways.

Friday, May 4, 2012

Bench Power Supply: Power Control

In this truly awful video, you can see my bench power supply at work.

For testing, I coded a function to cycle the voltage between 0-5.0V.  In reality, 0-100% duty cycle is the parameter the code changes. A "PWM'ed"  square wave(yellow trace) is fed to an RC filter, which is then buffered with an op-amp(the op amp output is the blue trace).

You can also see the LCD updating in realtime. The voltage reading is coming from the ADC on the ATmega 644. It's has a hard time keeping up with the displayed "SET" value, but there probably several factors, the biggest of which purely software related, I simply don't refresh the "widget" that displays the voltage reading any faster than 3Hz. 
(Ignore the Amperage settings/reading, they're not coded yet, the analog portions of that have me the most intimidated)




Anyways, crappy quality aside, this is a great demonstration of how PWM signals can be used to generate analog voltages from a digital MCU pin, and how "duty cycle" affects what comes out of a simple low-pass RC filter.


--P



Wednesday, May 2, 2012

JSIL

Just a short post:.

I think JSIL:

Is the bees knees.

It's a .Net bytecode (CIL, "common intermediate language") to JavaScript compiler.

Despite the fact that I don't blog about it often, .Net, its frameworks, libraries, tool, and the C# programming language are safely #1 at the top of tech things I love. My .Net Micro Framework project (still in progress, but on temporary hiatus), is my attempt to blend C# with my enthusiasm for embedded development.

Keep an eye on JSIL, I think it will go places. It's the way Silverlight should have been done.

--P