But it occurred to me today that the problem really breaks down into two hardware pieces:
- Power control for the oven
- Reading the thermocouple
The nice thing about the Toast-R-Reflow design is that the high voltage switching and control apparatus is a very static design. Since there are optoisolators driving the triacs, it really just amounts to treating the oven elements as if they were LEDs, and that's fairly trivial for Arduino/ATMel based systems.
There are a number of ways to read the thermocouple. There is, of course, the AD595AQ that I started with. Nowadays I'm using AD8495s instead, but in principle, you probably can get more accurate results with the MAX31855. It's a particularly good choice because the A/D converter is built right into the device. You just need to connect it up to 3 digital pins to make an SPI interface. SPI seems at first to be unfortunate, since most of my projects use i2c, but in this case, the interface is fairly easy to bit-bang. The other downside is it's a $8.19 part - double the price of the AD8495. But for your trouble, you get quarter-degree resolution and a signed 14 bit range - meaning you can read negative temperatures properly without resorting to supplying a reference voltage like for the AD8495.
I originally went with the AD8495 because the ATTiny85 only had a single pin to spare, so using it as an analog input was the direction I chose. One way to get more pins is to shift up to the ATTiny84. I was contemplating such a design when it further occurred to me that the i2c LCD GPIO chip has lots of pins to spare!
Of course, that means a fully customized version of the LiquidTWI2 library. And I'm already - more or less - heading down the road of of an ATMega328 based design with the LCD directly connected. In that design, I left the ISP pins unused so that I wouldn't have to protect them during programming, but as long as the CS line of the MAX31855 is not asserted (meaning there's a pull-up on its !CS pin), it can share SCK and MISO with ISP.
I was contemplating adding a 1.8 volt analog reference to that design to make better use of the available A/D resolution, but using the MAX31855 would obviate that. The only other downside is that the cost goes up, as it's a more expensive chip.
But I think, in the end, that that's the direction I'll go for the "next gen" controller design. It will eventually have a parameter and reflow curve editor UI built-in (since the ATMega has enough flash space). It'll have 3 buttons instead of 1 - up, down and select.
I originally went with the AD8495 because the ATTiny85 only had a single pin to spare, so using it as an analog input was the direction I chose. One way to get more pins is to shift up to the ATTiny84. I was contemplating such a design when it further occurred to me that the i2c LCD GPIO chip has lots of pins to spare!
Of course, that means a fully customized version of the LiquidTWI2 library. And I'm already - more or less - heading down the road of of an ATMega328 based design with the LCD directly connected. In that design, I left the ISP pins unused so that I wouldn't have to protect them during programming, but as long as the CS line of the MAX31855 is not asserted (meaning there's a pull-up on its !CS pin), it can share SCK and MISO with ISP.
I was contemplating adding a 1.8 volt analog reference to that design to make better use of the available A/D resolution, but using the MAX31855 would obviate that. The only other downside is that the cost goes up, as it's a more expensive chip.
But I think, in the end, that that's the direction I'll go for the "next gen" controller design. It will eventually have a parameter and reflow curve editor UI built-in (since the ATMega has enough flash space). It'll have 3 buttons instead of 1 - up, down and select.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.