Stc-1000+

Awesome, but until you start selling them preflashed there's no way I'm undertaking this adventure

Sent from my Galaxy Nexus using Home Brew mobile app

nickmv said:

1. Why is the Profile accessible through both the main menu, as well as the Set menu? This seems repetitive, and possibly confusing.

2. Based on #1, why not have the "Run" function located on the main menu instead of having it inside the "Set" menu?

So basically, the main menu would contain:
1. Run -- choose to then find a profile to execute. However, don't have settings on the Profiles when you choose. So basically, I'd press S to bring up the main menu, then choose "rn", then choose Pr0, for example, and it's done. No settings to bring up, etc. Just a very quick and to-the-point execution of a profile.

2. Set -- show all settings, but also show profiles. Or perhaps, somehow have the profiles as a submenu inside the Set menu. But bottomline, keep the settings of setpoints and durations for profiles somewhere inside the "set" menu, and nowhere else.


Thoughts?

Click to expand...

Ok, I'll address this part, since it seems the temperature readings are well within tolerance for you now.

Profiles should not be accessible both from main menu and set menu. If they are, something is wrong...
Ideally (from my point of view, that is from code), everything should be under main menu, but scrolling through 60 points of profile settings to get to the value you want to set is just going to be unusable. So I pretty much had to add submenus.
It might not be obvious to the non coder, but every value to be set, is under a submenu item, which is under a menu item. There is quite a bit of cleverness to get this working at all with this limited hardware. So, in short, I just don't have the freedom to move things around. It just has to be this way, if all the settings needed are going to fit, and not just have one long list.
Don't get me wrong, I hear what you are saying, it probably isn't the MOST intuitive interface, still I think I've done pretty good, given the limitations. Compare with the stock firmware. That would be the alternative, instead F00-F63 where you'd need the manual at hand, to know what you are actually setting...

disney7 said:

Hmm, I tried the current version twice and got the same results (buttons don't work) before I reverted back to the previous version (which still worked fine).

Alpha or Nick, any ideas why it might be doing this on mine? Anything different I can try?

BTW, I'm not supplying AC power to it when flashing. Doesn't seem to need it unless you think it might be causing my problem.

Thanks

Click to expand...

I have been investigating this a bit, but since I cant reproduce, it is very hard. As I said earlier, I've seen the issue, but not since I gave up on trying to use global state variable.
It seems very strange, that you still have this issue, even with latest code and it worries me. If you have the issue, then it might be due to some slight difference in revisions in the MCU, and then others may suffer from it as well.
I'll see if there is any other way I can pass the state from menu back without incurring RAM penalty, if not I can try to use another register perhaps and see if that solves the issue.
I can send you a PM, when I have uploaded new code, that could affect your situation.
Edit: And yes, do not have the STC-1000 powered when flashing. That is, it should not be plugged in at all. It does not seems like uploading code is the issue for you.

tom_hampton said:

Brewpi is interesting. I've been following it since Uberfridge days. However, there are still several issues with Elco's chosen method of control---and the basic implementation. Really the nicest thing about brewpi is the UI and its Rpi based features.

Specifically, it doesn't support direct heating of a fermentation vessel---ie, a heater attached to the side of the fermenter. Second, it requires a separate Arduino uno/leonardo, and associated hardware for every control point (fermenter, etc). The arduino alone costs more than an STC-1000, and I still need an SSR, and a temperature probe. With case an all, each Brewpi control point will cost around $40. Besides, I've already got the STC-1000's. I have a total of 6 managing my fermentation chamber and 4 separate fermenters. So...free or spend another $240+ for a BrewPi setup?

So, if a primitive protocol could be implemented using the EUSART to allow I2C type of access to several STC-1000's that are then managed by an Rpi (or a Teensy 3.1) that would have a lot of value.

Click to expand...

While I think it might be possible to add communication (or rather write a new firmware for this). I don't think it will as useful as you think.
BrewPi is an awesome project. The regulation algorithm it uses 1. requires both beer temp and fridge temp (STC-1000 has just one sensor), 2. I think it would be a real challenge just fitting anything near this algorithm in the tiny controller that the STC-1000 sports.
Anyway, this is well outside this project. But if someone wants to give it a shot, then go for it
Edit: I must admit, I had not read the post carefully enough. If a simpler control algorithm is sufficient, then this can probably be done. You will need to do some hacking on the BrewPi side as well, as it communicates by sending JSON strings. That will not be feasible for this. The PIC16F1828 in the STC-1000 is an order of magnitude smaller than the ATmega328 in the Arduino. So, still anything like this will not be included in this project, but is not unreasonable for another firmware. I think you are even lucky enough that the communication pins can be directed to the pins on the programming header, so they can be easily accessed.

alphaomega said:

I have been investigating this a bit, but since I cant reproduce, it is very hard. As I said earlier, I've seen the issue, but not since I gave up on trying to use global state variable.
It seems very strange, that you still have this issue, even with latest code and it worries me. If you have the issue, then it might be due to some slight difference in revisions in the MCU, and then others may suffer from it as well.
I'll see if there is any other way I can pass the state from menu back without incurring RAM penalty, if not I can try to use another register perhaps and see if that solves the issue.
I can send you a PM, when I have uploaded new code, that could affect your situation.

Click to expand...

Thanks Alpha. I just tried the e92c5e7214 commit and am having the same problem. This unit was advertised as being an Elitech STC-1000, but I bought it through an Amazon vendor, so who really knows.

Alpha, if you'd like, I can ship this unit to you at some point (though it might take a while, I'm in the US). Also, if there is any diagnostic I can do for you, please let me know. I'm no embedded coder, but I am fairly handy with electronics in general.

disney7 said:

Thanks Alpha. I just tried the e92c5e7214 commit and am having the same problem. This unit was advertised as being an Elitech STC-1000, but I bought it through an Amazon vendor, so who really knows.

Alpha, if you'd like, I can ship this unit to you at some point (though it might take a while, I'm in the US). Also, if there is any diagnostic I can do for you, please let me know. I'm no imbedded coder, but I am fairly handy with electronics in general.

Click to expand...

The shouldn't be necessary, but if you are up for it, I would like to try first to change the register used for flagging menu state. And if that still does not work, then I would have to make a change to the code, that I would rather avoid. Would that be ok?

No problem, I'll drop anything on it that you want me to try.

Also, for reference, I'm attaching pics of the board version numbers on this unit.

Also, it looks like a ton of vendors make this unit. Elitech, AGPTek, Image, and I'm sure a bunch of others. I wonder what the story is there? They're all copies? Licensed manufacturers? Chinese ripoffs? All made by the same place and re-branded? (The name on the box is different, but the rest of the box even looks the same)

They all appear to be the same thing, no immediately noticeable difference in the housings. Some of the labels on the top of the unit are slightly different.

Then there is this one:

http://www.amazon.com/dp/B00F05UI8O/?tag=skimlinks_replacement-20

Not advertised as a STC-1000, but it is at least a copy and obviously has different code as it reads in Fahrenheit.

I'll check the version with my board as well, but I don't think that will tell much.
I'll try to add a command to the sketch to show the device id and revision, that will tell if the MCU is the same revision or not.

I have no idea how the Chinese market works, but I would not be all that surprised if there is one place of manufacture and they are just re-branded, licensed or not.

The Fahrenheit controller you referred to is almost certainly single stage (i.e. heat OR cool, not both). The enclosure seems popular, there are yet other controllers with the same. The hardware inside can be (and probably is) completely different.

OK, seems I was mistaken. Setting the setpoints is actually accessible through the main menu only. I was thinking I could get to it under the Set menu as well, but I was mistaken. My bad.

Regardless, I guess the main thing is that I think the run function should be under the main menu, where you can execute profiles, etc, and that profiles should be elsewhere.

But again, you're the author, and it's certainly not a show stopper. If you feel like it's better with the way it currently is, then that's fine. No worries at all. I just figured it might be simpler to have the run function easily accessible with minimal button presses.

tom_hampton said:

So, if a primitive protocol could be implemented using the EUSART to allow I2C type of access to several STC-1000's that are then managed by an Rpi (or a Teensy 3.1) that would have a lot of value.

Click to expand...

This is along the lines I was thinking. Rather than profiles you program from the front panel of the STC-1000+, you interface something like the Jeelabs v3 click here onto the PIC. Then program the pic to adjust the set point based on what you send it from the R Pi.

To create other wireless sensors, you just need the Jeelabs V3 and a thermistor probe (e.g. in a thermowell in your carboy, in your mash tun, brew kettle, etc.).

The work these guys are doing with the STC-1000 is great, and I see the above outlined project as a fork of this effort (unless anyone objects). I have STC-1000s on order so I can help with this thread, and to use as a platform for the above.

Happy St. Paddy's!
Cheers,
Gary

Edit: checked prices and the Jeelabs V3 and V6 are almost the same price, but the V6 is closer to a standard Arduino so may be the better choice.

nickmv said:

OK, seems I was mistaken. Setting the setpoints is actually accessible through the main menu only. I was thinking I could get to it under the Set menu as well, but I was mistaken. My bad.

Regardless, I guess the main thing is that I think the run function should be under the main menu, where you can execute profiles, etc, and that profiles should be elsewhere.

But again, you're the author, and it's certainly not a show stopper. If you feel like it's better with the way it currently is, then that's fine. No worries at all. I just figured it might be simpler to have the run function easily accessible with minimal button presses.

Click to expand...

I'm not saying it is better this way, in fact I do think you have a point. I am saying given the extremely limited hardware, I simply can't move it. To even manage to have sub-menus, I need to be able to make assumptions as to how the data is laid out. And moving 'rn' to the main menu, would break the pattern.

ulnpiper said:

This is along the lines I was thinking. Rather than profiles you program from the front panel of the STC-1000+, you interface something like the Jeelabs v3 click here onto the PIC. Then program the pic to adjust the set point based on what you send it from the R Pi.

To create other wireless sensors, you just need the Jeelabs V3 and a thermistor probe (e.g. in a thermowell in your carboy, in your mash tun, brew kettle, etc.).

The work these guys are doing with the STC-1000 is great, and I see the above outlined project as a fork of this effort (unless anyone objects). I have STC-1000s on order so I can help with this thread, and to use as a platform for the above.

Happy St. Paddy's!
Cheers,
Gary

Edit: checked prices and the Jeelabs V3 and V6 are almost the same price, but the V6 is closer to a standard Arduino so may be the better choice.

Click to expand...

I've been messing about with JY-MCU (HC05) bluetooth serial adapters before, and like them a lot. They are dirt cheap, are easy to use and work well. So, if I were to try interface the STC-1000, that would be what I would look at first. It is easy to interface with android or any PC with a bluetooth adapter.

Edit: I just checked the datasheet, and I was wrong... The serial lines are not brought out to the programming header, so interfacing the STC-1000 will not be that easy.

butterpants said:

Awesome, but until you start selling them preflashed there's no way I'm undertaking this adventure.

Click to expand...

This is most definitely in the works, along with dual relay Fahrenheit controllers with standard firmware.

butterpants said:

Awesome, but until you start selling them preflashed there's no way I'm undertaking this adventure

Sent from my Galaxy Nexus using Home Brew mobile app

Click to expand...

sdgenxr said:

This is most definitely in the works, along with dual relay Fahrenheit controllers with standard firmware.

Click to expand...

Guys...

Don't start talking about selling stuff here or this thread will be closed just like "the other one."

You *may* be able to open a thread in Group Buys or so, all depending if and how it fits within forum regulations. That means not for profit, sold at cost, etc. Or get a vendor account. Talk to a mod when in doubt.

This thread is for development only.

IslandLizard said:

This thread is for development only.

Click to expand...

Not to mention, it's way too early to be talking about commercializing something that JUST started. There's bugs in the code, and it's just WAY too far out to be discussing something like that.

At least let the project get to a stable version (which it's not close to) before discussing such things, and keep it within forum rules.

The instant I saw someone mention commercializing, I shook my head and went "oh no, here we go".

Bummer... Looking at it - RB4 & RB7 (SDA/SCL) are used by the display.. it would be awesome to get rid of the thermistor's and replace them with a DS18B20 for accuracy. I ordered another STC from amazon to play with - it should get here this week.

atoughram said:

Bummer... Looking at it - RB4 & RB7 (SDA/SCL) are used by the display.. it would be awesome to get rid of the thermistor's and replace them with a DS18B20 for accuracy. I ordered another STC from amazon to play with - it should get here this week.

Click to expand...

Wait, so what's stopping you from replacing the thermistor with a new one, and changing the lookup table to match the resistive values for the new probe?

Also, I think you'll find that the probe here is pretty damn accurate, at least when it comes to measuring fermentation temps. A little calibration is needed, but see my post on the previous page. I did some testing last night and was impressed with the results, given the fact that this is a very cheap controller.

Edit: See below. As you can see, based off a 32.0F calibration technique (which is far from fermentation zone), the largest variance noted in the probe from 60-80 degrees was 0.2 degrees at one point (see column Delta-T (TC)), and that most certainly could be negligible result.

Have you considered making the temp readout scale selectable ?
That was the original problem with the stc-1000 - only Celsius.

The conversion is trivial, especially when storing temps as 10x the value.
This simplifies your code maintenance at the expense of another config register.

adam01 said:

Have you considered making the temp readout scale selectable ?
That was the original problem with the stc-1000 - only Celsius.

The conversion is trivial, especially when storing temps as 10x the value.
This simplifies your code maintenance at the expense of another config register.

Click to expand...

I'm 99% sure he's gonna tell you it's a RAM issue. RAM is super scarce on this device, and he was unable to add a single variable previously in some other maintenance attempts he made last week. Now, I'm guessing if he deleted a bunch of the profiles and features, he could fit that in, but that would ruin the point of the software.

I know it sounds simple -- start off with Celsius, and depending on a selectable flag, you'd perform a predefined operation (that being the conversion of C to F) upon the original temp value. However, all that extra work takes up space. Space which the device doesn't have. It'd be SOOO nice if the thing had a few megs of space to work with, but it doesn't.

So that brings up the next project -- resoldering on a new storage chip onto the STC. Behold, the Super-STC-1000+!

Alpha -- exactly how much ram IS available? 1 megabyte? Less? What about EEPROM?

nickmv said:

Alpha -- exactly how much ram IS available? 1 megabyte? Less? What about EEPROM?

Click to expand...

I'm not Alpha but I believe its 8K for program space.

http://ww1.microchip.com/downloads/en/DeviceDoc/41419D.pdf

atoughram said:

I'm not Alpha but I believe its 8K for program space.

http://ww1.microchip.com/downloads/en/DeviceDoc/41419D.pdf

Click to expand...

Haha crap, yeah I figured 1MB was WAY overstating the space. Sure enough.

Remember, devices will never need more than 640kb of memory!!

adam01 said:

Have you considered making the temp readout scale selectable ?
That was the original problem with the stc-1000 - only Celsius.

The conversion is trivial, especially when storing temps as 10x the value.
This simplifies your code maintenance at the expense of another config register.

Click to expand...

Well it IS selectable, sort of... It's just not runtime selectable.
The main issue is that I need to store temperatures, if you switch scale, all temperatures are stored are invalid. Well... It might be OK to simply don't care that all data is invalid, and leave it up to the user to set valid data again. Also limits would need to to be changed and that does take up some resources.
Conversion is not trivial. The controller has no hardware multiplier or divider. So, conversion will be costly.
I agree it would be nice, but I don't think it will be worth the cost, as other functionality would need to be scrapped.

nickmv said:

I'll let alpha comment, but 99% sure he's gonna tell you it's a RAM issue. RAM is super scarce on this device, and he was unable to add a single variable previously in some other maintenance attempts he made last week. Now, I'm guessing if he deleted a bunch of the profiles and features, he could fit that in, but that would ruin the point of the software.

I know it sounds simple -- start off with Celsius, and depending on a selectable flag, you'd perform a predefined operation (that being the conversion of C to F) upon the original temp value. However, all that extra work takes up space. Space which the device doesn't have. It'd be SOOO nice if the thing had a few megs of space to work with, but it doesn't.

Alpha -- exactly how much ram IS available? 1 megabyte? Less? What about EEPROM?

Click to expand...

Yeah... 128 bytes of RAM. That is bytes... No prefix.
EEPROM is also 128 bytes, but that is only usable for configuration.
There's a fair amount of black magic going into stretching the resources. You simple can't write code the way you normally should. Every byte counts.

You could do advanced stuff. I mean, it would be possible to do PID control and stuff, you just can't do much else...

It really is a matter of picking your battles. I want to make as much as I can out of it, but trade off's have to be made.

nickmv said:

Wait, so what's stopping you from replacing the thermistor with a new one, and changing the lookup table to match the resistive values for the new probe?

Also, I think you'll find that the probe here is pretty damn accurate, at least when it comes to measuring fermentation temps. A little calibration is needed, but see my post on the previous page. I did some testing last night and was impressed with the results, given the fact that this is a very cheap controller.

Edit: See below. As you can see, based off a 32.0F calibration technique (which is far from fermentation zone), the largest variance noted in the probe from 60-80 degrees was 0.2 degrees at one point (see column Delta-T (TC)), and that most certainly could be negligible result.

Click to expand...

While I have no doubts of your testing, I just prefer the DS18B20 - but thats not an option in it's current form factor. I've attempted to use an NTC thermistor without the lookup table but the lack of linearity makes that quite tough. (Steinhart-Hart equation?) It seems that a RTD would work too without a major circuit change also. But in the end your right, as long as it's somewhat accurate and repeatable - it's good enough.

Alphaomega's work is awesome! Thank You!

atoughram said:

I'm not Alpha but I believe its 8K for program space.

http://ww1.microchip.com/downloads/en/DeviceDoc/41419D.pdf

Click to expand...

Well, yeah, but that is program space and while that is ridiculously small, it is not the biggest problem (and really 8K is not really 8K either, it is actually 4K of instructions, as the instructions are 14 bits wide)

alphaomega said:

Well, yeah, but that is program space and while that is ridiculously small, it is not the biggest problem (and really 8K is not really 8K either, it is 4K of instructions.

Click to expand...

You might be able to squeak out a bit more using ASM but there's a learning curve to deal with (speaking for myself.).

EDIT - Now I remember.... 14 bit instructions.... thanks for reminding me.

Microchip usually have different devices with more RAM/code memory that are pin to pin compatible, did you guys check their device list, replacing the micro on the PCB should be easy and would offer much more room for us ot play with

AngryMonk said:

Microchip usually have different devices with more RAM/code memory that are pin to pin compatible, did you guys check their device list, replacing the micro on the PCB should be easy and would offer much more room for us ot play with

Click to expand...

That's completely infeasible for the majority of us, so it should absolutely NOT be done.

You're asking us to go from simple soldering to removing chips and replacing them. That's getting out of control, and then on top of that, you'd have to create multiple versions of code with different feature sets.

I realize you're getting ambitious here and that's great, but it's too much. We're realistically limited to the hardware provided, and shouldn't expect that any of us are going to upgrade memory chips on the device.

atoughram said:

You might be able to squeak out a bit more using ASM but there's a learning curve to deal with (speaking for myself.).

EDIT - Now I remember.... 14 bit instructions.... thanks for reminding me.

Click to expand...

Absolutely. But I'm pretty fluent in C and productivity in ASM is terrible... Especially for these chips as you need to handle banking and stuff yourself. It has crossed my mind though, and frankly for this limited device, ASM might have been better.

AngryMonk said:

Microchip usually have different devices with more RAM/code memory that are pin to pin compatible, did you guys check their device list, replacing the micro on the PCB should be easy and would offer much more room for us ot play with

Click to expand...

Oh yeah. The 16F1829 would be a big improvement, but still pretty low. There might be others even better. But they are surface mounted and very badly located for replacing. So, replacement is not trivial.
My reasoning for this project, is to make as good as fermentation controller as I can out of a stock STC-1000, make it simple enough so that almost anyone with basic skills can upgrade and with as basic tools as possible. No, it is not going to do everything. But it will be low cost and open source and better suited for fermenting than the stock firmware.

disney7 said:

Awesome work AlphaOmega!

I had to adjust the STC-1000 down by 2.6*F to match my Thermapen at 56*F. Then I tested it in some water that the Thermapen said was 76.4*F and the STC was reading 0.2* lower. So, it's pretty close.

I'll do some more testing this weekend.

Click to expand...

Could someone explain how you go about calibrating the STC-1000 in reference to a thermometer. I would love to flash and calibrate my STC-1000, but I have no training in programming or electronics. This is really cool stuff!!! Thanks guys!!!

nickmv said:

That's completely infeasible for the majority of us, so it should absolutely NOT be done.

You're asking us to go from simple soldering to removing chips and replacing them. That's getting out of control, and then on top of that, you'd have to create multiple versions of code with different feature sets.

I realize you're getting ambitious here and that's great, but it's too much. We're realistically limited to the hardware provided, and shouldn't expect that any of us are going to upgrade memory chips on the device.

Click to expand...

I feel like I'm being told what I can do and can't, not sure how much I like that. What about every one decide what they want to do ? And since I've been told no, I'll work on that and see what I can propose, most of us actually CAN replace a chip.

Brew free or die !

AngryMonk said:

I feel like I'm being told what I can do and can't, not sure how much I like that. What about every one decide what they want to do ? And since I've been told no, I'll work on that and see what I can propose, most of us actually CAN replace a chip.

Brew free or die !

Click to expand...

That's the spirit!
I had to take my development STC apart for reverse engineering, and it is an itch with a b to desolder the PCB with the buttons and LCD and get it back in one piece, but perfectly doable. I say go for it

AngryMonk said:

I feel like I'm being told what I can do and can't, not sure how much I like that. What about every one decide what they want to do ? And since I've been told no, I'll work on that and see what I can propose, most of us actually CAN replace a chip.

Brew free or die !

Click to expand...

There you go, as easy as 16F1829. It is the same as the 16F1828 used on the STC but:

Program memory 14KB vs 7KB on the 16F1828
RAM 1KB vs 256B on the 16F1828

You guys have fun now, time for a beer.

AngryMonk said:

There you go, as easy as 16F1829. It is the same as the 16F1828 used on the STC but:

Program memory 14KB vs 7KB on the 16F1828
RAM 1KB vs 256B on the 16F1828

You guys have fun now, time for a beer.

Click to expand...

Wait... what? That was not the challenge... Besides I already mentioned the 16F1829 a few posts ago.

alphaomega said:

Wait... what? That was not the challenge... Besides I already mentioned the 16F1829 a few posts ago.

Click to expand...

I did not read the whole thread, and do not want to take anything from you There is just so much you can fit in 256B/7KB, if somebody really want to get fancy with what that device will be doing, an upgrade is possible, I would actually upgrade and keep previous chip with stock SW if it was me...

AngryMonk said:

I did not read the whole thread, and do not want to take anything from you There is just so much you can fit in 256B/7KB, if somebody really want to get fancy with what that device will be doing, an upgrade is possible, I would actually upgrade and keep previous chip with stock SW if it was me...

Click to expand...

Yeah, that would not be a bad idea at all. I actually did not realise how tiny the chip was, when I reverse engineered the hardware. If I knew then, I probably would have done just that and developed STC-1000+ on a 'fresh' STC-1000.
Then I could have played a bit with fancier stuff on the 'supercharged' one.
As it stands now, I really would not want to perform that operation again. I didn't manage to get the board off without breaking a PCB trace, but granted I'm not great at desoldering.

AngryMonk said:

I feel like I'm being told what I can do and can't, not sure how much I like that. What about every one decide what they want to do ? And since I've been told no, I'll work on that and see what I can propose, most of us actually CAN replace a chip.

Brew free or die !

Click to expand...

LOL, nobody's telling you what you can or can't do. I'm just telling you what Alpha is likely NOT going to do. He also just commented on that and pretty much affirmed what I already figured -- that his intentions are to get a stock STC-1000 flashed as easily as possible, for people to use with extra features. Obviously I don't speak for him, so if he decides to steer the project elsewhere, we'll see.

You're more than welcome to tackle it yourself. I was just simply saying that it's unlikely that the project's going to steer in the direction of replacing chips, etc.

That's just being realistic.

If you manage to do it, have at it and let us know how it goes.

Celsius to Fahrenheit IS simple. No multiplication or division.

F = 320 + 2*temp + 16*temp - stored as 10x real temp.

Both multiplies can be converted to left shifts.

F = ctemp + (ctemp <<3);
F = 2*F + 320;

Add it to your maybe list...

adam01 said:

Celsius to Fahrenheit IS simple. No multiplication or division.

F = 320 + 2*temp + 16*temp - stored as 10x real temp.

Both multiplies can be converted to left shifts.

F = ctemp + (ctemp <<3);
F = 2*F + 320;

Add it to your maybe list...

Click to expand...

The project is open-source.....

It would help if others could create different versions of the software. Not sure if you have programming experience, but just noting that if you do, don't necessarily just leave it up to him to do something. Play with it. Wish I had the experience to, but unfortunately I can just read code, but not really contribute code.

Wow, this is great work, and I'm definitely interested in doing this! The programmable profiles would be extremely handy, and not having to get my phone out to convert F to C every time I adjusted my controller would be soooo nice! Thanks alphaomega

adam01 said:

Celsius to Fahrenheit IS simple. No multiplication or division.

F = 320 + 2*temp + 16*temp - stored as 10x real temp.

Both multiplies can be converted to left shifts.

F = ctemp + (ctemp <<3);
F = 2*F + 320;

Add it to your maybe list...

Click to expand...

Hm.. I was stuck on the 9/5 fraction, I didn't even consider what it actually came out to...
You are right. That actually might work.
I will add this to the list, I can't promise anything, as I am approaching a very hard limit, but this is definitely good advice. I can promise I will look into it.

Edit: Ok, I thought about it. It will not be that easy. There is the issue of setting temperature values. This would still need to be done in C then, but converted to F for display. So one press, will give 0.2 increase most of the time, but not always, which would be weird.
Also, maintaining the code i think is pretty straight forward done this way. There are no special cases. If I were to change, then Fahrenheit mode, would actually be more costly than C mode and could potentially be more prone to stack overflows and stuff.

Edit2: Is it really that big of a deal anyway? I mean, who really wants to switch between scales?

"...I mean, who really wants to switch between scales?"

Nobody, especially while drinking.

If its only a display option then its easy. Compute in Celsius and display in Fahrenheit. Of course, setup either is convert back or always program in Celsius.

But priority first - get it stable...