Time has passed, and the first few of my new batch of components arrived in this morning's post - well, the Pro Mini for this project has arrived at least (but I also treated myself to some 4-pin DuPont cables for IIC device connections, and another RTC after the DS1301 proved to be cr@p, so I've now got an IIC DS3231 board, which I hope will be better - or at least work!!).
In the intervening time, I've made a start on developing the code for my gauge. It consists mainly of 3 parts - the first part deals with the sensor itself, getting the 'ping' reading (which is the echo return time in microseconds), and converting that into the sensor-to-water distance in cms. From this measurement, and knowing the distance from the sensor to the highest and lowest water levels of the tank, I can work out the percentage capacity used or remaining in the tank.
As an afterthought, I've also included a HIGH/LOW test on a pin I've called OpMode, which I will connect to a 3-pin header with a jumper allowing it to be connected to Vcc or GND. This will facilitate the display of either the percentage value (as described above), or the actual distance measured. This second mode will allow me calibrate the unit, as I am not convinced it will be accurate to 3mm as claimed by the manufacturer. In fact I have seen many articles that show errors of several cms, even at just half the suggested max 400cm capability of the unit. Remembering that all my purchases are of cheap (and therefore most likely 'seconds' quality, or poor quality knock-offs) Chinese ebay items, so I am fully expecting to need to add some correction factors in once I have all the parts and can do some testing. I'll probably put up a post showing my results when I have all the parts and can do some controlled experiments.
The second section of my code simply takes the resulting number (either a distance in cms, or percentage), and breaks it down into individual digits - hundreds, tens, and units. This means I will only use a maximum 3 of the 4 digits on the LED, so I can use the 4th to indicate the OpMode (test/normal). Note - if the first digit is 0, I want to display nothing on that digit in the display, rather than prefixing the rest of the number with a zero.
The third part then takes each of the three digits and OpMode, and displays them on the LED digits 1-4 sequentially. The LED is a common cathode device, which means that you can display the same value on all 4 digits at the same time, but if you want each to show a different value, then you have to do them one at a time. Switch on digit 1 and light up all the correct segments; wait very briefly; then switch them all off again and move on to digit 2 and repeat. The trick is to do this while looping around all 4 digits fast enough to make it appear they are all being displayed simultaneously. I have done this by creating a subroutine called displayDigit, and passing it the digit to activate, and the value to be displayed, and placing 3 calls to it from the loop() subroutine.
In relation to my suspected faux pas regarding buying the Pro Mini board without an ISP interface board to program it, I am pleased to say that further research has reveled that the articles I referred to previously, whilst giving me hope of potential work-arounds, were perhaps over-complicating the procedure. Thanks to Julian Ilett's youtube video - Arduino as an ISP, it looks like using an existing Arduino to load a sketch OR a bootloader to the Pro Mini or any other xxuino device, is a piece of cake! I love Julian's videos - he has a great way of explaining things. If you watched this video, I have already cobbled together my own version of his 3 LED ArduinoISP monitoring widget, and have installed the sketch on my Uno so I can watch the heartbeat.
For those that haven't yet watched it, there is a 2 stage process for loading a sketch or bootloader to a second device... Since I am using my Uno as the programmer, and Pro Mini as the target, I'll use these in my description below, but the concept holds true for programming any target xxuino from any programmer xxuino (as far as I can tell) though the specific pin connections may vary from device to device - especially if they don't have an ISP6 6-pin block and you are having to use digital pin equivalents.
So the first step is to load the "ArduinoISP" sketch onto my Uno, in exactly the same way I load normal sketches, to turn it into a pass-thru ISP controller. The second step is to load my water gauge sketch into the IDE, then select Pro Mini as the board. Now, rather than the normal compile and upload operation, go to Tools/Programmer and select the "Arduino as ISP" option. This compiles the sketch in the IDE and passes the compiled code to the sketch that is running on the Uno. This sketch allows for a stream of compiled code to be received from the IDE, but NOT loaded into memory by the bootloader. Instead, it passes the compiled code on to the Pro Mini where its bootloader DOES store it in the Pro Mini's memory, ready to go when disconnected from the Uno and given its own power supply.
In case you need to actually install the bootloader on the Pro Mini, then when you have the ArduinoISP sketch loaded on the Uno, select the Pro Mini as the target board again, then go to Tools/Programmer, and use the "Install Bootloader" option. I am not 100% sure if the first step is really required, but I think that without it, you may end up potentially screwing the bootloader on the Uno or have the whole operation fail because the IDE see's an Uno board at the other end of the USB cable, rather than leap-frogging to the Pro Mini selected. Personally - I'm not game to test out my theory - but if you are adventurous, go ahead and try, and let me know what happens in the comments below.
OK - So, now I just want to get the rest of my day at work over and done with , so I can get home and start tinkering this evening - first job, connect header pins to Pro Mini so I can plug it into my breadboard and see if it has a bootloader and 'blink' sketch loaded :)
No comments:
Post a Comment