When it comes to small stand alone micro controller projects I did quite a lot on the PIC16C84 which were really nice. Things like a device actually powered by a 9 pin RS232 port and on a board fitted between the pins of the plug so in the socket on the end of a lead, that does shit with bit-bashed serial. I made my own assembler for that too. They really were fun devices, and I recall when my kids were young making a pedestrian crossing for a Scalextric set with red/amber/green lights, button, red/green "cross" man, beeps, the lot. Indeed, for this project one of those would seem fine, but times have changed a bit...
The project
The project is simple - a device with a temperature sense and an infra red LED. The plan is to send the air-con unit commands to control the temperature properly. The damn air con is stupid. This time of year is especially a problem as my office is starting the day below 21℃ and later in the afternoon is above 21℃.
I set the air-con to heat to 21℃ and it does well, maybe as high as 21.7℃ but if the room starts to get hotter it stops.
I set the air-con to cool to 21℃ and it does well, maybe as low as 21.1℃ but if the room starts to get colder it stops.
OK, so I set "auto" mode for 21℃ and I even turn off the "eco" mode that makes for a wider margin. I can find it sat in heat mode but not heating or in cool mode and not cooling as low as 18℃ or as high as 24℃, or so it seems. The margins it uses are more than my personal comfort margins, and it is for my personal comfort that I had air-con installed!
I can achieve what I want only by changing manually between cool and heat modes when, during the day, the temperature of the room with no air-con starts to get above 21℃. I find it annoying that it takes me some time to realise it needs changing, suffering extra heat or cold for like half an hour and then looking at the wall thermometer and realising the problem.
But it having a tighter margin does not cause it to go mad - heating and cooling and heating and cooling, the point in the day it is hotter is pretty clear. If I allowed even a ±0.5℃ margin, e.g. 20℃ to 21℃ it would not spend time flapping between heat and cool.
So, I have found a nice temperature sensor, the ADT7420, which has a typical accuracy of 0.0017℃ (max 0.2℃). An IR LED is simple enough. So I could code something to control the air-con via what it thinks is the IR remote. All I then need to do is blu-tac up the sounder that beeps when you use the remote and I can have a stable temperature all year round.
The platform
This is what is tricky these days as so many choices.
At one extreme I could go old-school and make up a PIC16C84 or something. I doubt wire wrapped 65C102 is sensible these days :-) To be honest this is tempting - they were still "fun", like Z80 and 6502, but you could do shit with one leaded chip and a couple of other components on a bit of veroboard.
At the other end I could fit something to a PC. I have a linux PC in this room certainly but other rooms could do with this too.
In between, well, at the low end, things like Arduino or ARM Cortex and some assembler.
Or, at the higher end, maybe a Raspberry Pi, linux, and USB attached temperature sensors and IR emitter.
Choices, choices.
P.S. Worth mentioning that is it nice that things like the stupid remote control for the air-con is still itself a small micro-controller based device. You can tell as it does not take 5 minutes to boot up when you change batteries, and does not need s/w updates every week. That is good old fashioned "real" software... Old school.
P.P.S. I am almost disappointed - but someone makes such a gadget, so I am going to try it. If any good (or if not) I'll blog about it...
If you really want to write in assembler you should still either use a PIC (probably not a 16C84) or an Atmel AVR (like an AVR tiny). The modern small processors have inbuilt oscillators which mean you may get away without a crystal, though I suspect for a reliable IR remote you may still need one. Both vendors produce reasonable IDEs with C compilers, though not sure what the non-Windows support looks like.
ReplyDeleteARM Cortex covers an enormous range of things, from Cortext-M1 which is supposed to compete with small 8-bit processor to the Cortex-Axx stuff which is in the smartphone territory.
Surely you should be looking to use the Raspberry Pi Zero though...
I'd suggest Arm Cortex-M(3 or 4) like this dev-board http://uk.farnell.com/stmicroelectronics/nucleo-f411re/dev-board-stm32f411re-cortex-m4/dp/2433469
ReplyDeleteand C/C++. You will probably find it is massivly overkill for the task, which is a good thing(feeling limited in a small run task means it takes longer to get it working or have to re-design the hardware, while it is usually easy to cost-down later if mass-producing, but you knew that... ).
Linaro provide a GCC tool-chain and libraries that are suitable, https://github.com/texane/stlink provides what is effectivly a GDB server for the on-board jtag interface, or OpenOCD works.
With the availability of good compilers on reasonable sized devices, there is no need to resort to writing the whole thing in assembler.
(Actually I'll add a rider on that, the M0, M0+ and M1 are arm6-m based, while the M3, M4 and M7 are arm7-m based. The arm7-m based units have a very nice new vector interrupt controller which only requires function pointers to extern "C" void func(void) functions, and thus requires no special magic to write interrupt handlers. I can't say if the arm6-m devices do the same thing or not.
Ah, devices that don't require weekly software updates. There's something to be said for that. At times I feel like a slave to computers, constantly having to update the damned things.
ReplyDeleteI've just finished programming a three-axis CNC controller (i.e. three stepper motors and drill power on/off with three limit sensors) with drill and route modes on a PIC 16f872 using just 636 program words.
ReplyDeleteI used the Linux gpasm tools and ran it through simulation tests using the gpsim package.
The chip only cost £2.87 plus £0.30 for a 20MHz crystal - less money than your temperature sensor alone. With its low power consumption and sleep modes, you could run such a beast for ages on a 9V battery (via a regulator of course).
If you haven't forgotten the PIC16C84 instruction set then programming any member of the PIC16 family is no problem as they all use the same one. Oh and the 16F872 has a built-in i2c port which would make interfacing with the ADT7420 much easier.
Alternative sensors could be the DS18B20-PAR which is through-hole mounting if you don't want to get into surface mount components. It is a 12 bit device with 0.0625 degrees C precision and +/-0.5 degrees C accuracy and has a 1-Wire interface so you need only a single I/O line to talk to it. It also has programmable min and max temperature alarm limits that might be useful.
Surely with the cost of the mechanics for a CNC milling machine, saving a few quid on the controller by using a PIC is pointless?
DeleteNot exactly. I designed and built the drilling machine mostly out of old printer parts.
DeleteThe original processing core was a 100MHz 486 running Damn Small Linux with a custom kernel. That PC has finally died so I'm revamping the machine as a USB peripheral with an FTDI USB->Serial converter talking to a PIC16F872.
The frontend is also getting a makeover with a brand new graphical interface written in C++/Qt4/5. I'll be putting the new schematics and firmware/software on my site when I'm finished:
https://baron.bologrew.net/Drillcon100.html
With the expected speed increase, I'm hoping the routing mode will be a lot more useful for drawing component outlines on PCBs and there's a chance that my homemade laser cutter add-on will finally be usable which would let me cut masks for solder paste.
Why do air conditioners have such a wide margin between heating and cooling when in "auto" mode? If it is to prevent the unit from oscillating forth and back between heating and cooling, surely this could be eliminated with a basic algorithm that mandates a minimum time period (say 30 mins) between any flipping between heating and cooling.
ReplyDeleteThere is another platform option you should consider, the ESP8266. It was designed as a wifi-to-serial bridge but it's a microcontroller in its own right and being used for all sorts of things beyond its original purpose. I would confidently say that even for someone with lots of experience with PIC development, that you could get this particular project working faster on this platform, especially if you use a DS18b20 as suggested above.
ReplyDeleteYou can write in C on it or install a third party firmware called NodeMCU that lets you write in Lua. I believe you can code in assembly but if you WANT to do that, then you probably would be better off with the PIC.
NodeMCU has a very functional OneWire module but, unlike the PIC, in-built modules for all sorts of other higher-level things too like HTTP, SNTP and MQTT.
This would also appeal to your fondness for putting things on the internet (IPv6 support is sadly non-existent at the moment).
I guess you would have to bit-bang the IR LED aspect but at the frequency you're talking about this shouldn't be any harder than it would be on the PIC. There are some limitations with monopolising the CPU by using timer delays since it needs to handle wifi / serial timing in addition to whatever code you're running.
The cheapest version of the part is about $2.50, along with another $2 for a 3.3v usb-to-serial adapter needed to program it.
It's also a rare example in the integrated circuit world of an original Chinese design, with the documentation to prove it. Have a google, I think it's the most interesting microcontroller development since the Arduino (which it's often used in combination with).