11. Input devices¶
My individual assignment this week was add a sensor to a microcontroller board and read it, and my group assignment was to use an oscilloscope to observe an input devices analogue levels and digital signals.
Our group assignment this week was to probe an input device and read its analogue levels and digital signals. To do this, we used an Arduino Uno with a couple of potentiometers that controlled the PWM of an LED. We measured the analog signals from the potentiometer to the arduino for our analog level reading, and we looked at the PWM signals from the arduino out to the LED for our digital signals. Our with the small blue rotary potentiometer.
Then we turned the potentiometer and watched how the analog voltage level went up and down along with it.
Then we wanted to try doing the same thing with a linear potentiometer because we had a few laying around the lab. We got it wired up correctly, then we tested it out on the Oscilloscope.
Then we went on to reading the PWM signals from the arduino to the LED. We hooked up the leads in the correct places first.
Then we observed the PWM signals with both the rotary and the linear potentiometers.
Then, lastly, we wanted to look at both the Analog and the Digital readings at the same time, so we hooked the second probe up to our machine and turned on the arduino once again.
I decided to start this week off simple because of the short time I have. The first thing I made to observe was the button example that Neil provided in this week’s notes. I used the components that he had in his example, but I also added in an led that turns on whenever signals are sent from the chip to the serial port so you can see if your data is going through or not.
I went back into eagle to start getting my board designed. The first thing I did was create a new project named “Input_Week_Board” then I created a schematic in it. I added a frame to the schematic for a size reference, then I found all of my parts and connected them correctly. My finished schematic is below.
Then I opened up my schematic in the board editor. I moved the parts around until I settled on a layout that I thought would look good.
Then, I made sure that all of my design rules were in place before running the autorouter. I set all of the widths and clearances to 16 mil, because that’s the width of the bit that I will be cutting with, then I ran the autorouter. At first it wasn’t able to find any working paths, so I switched up the layout just a bit and then it worked fine.
I saw that there was a fair amount of empty space with this layout, though, so I condescend a few of the pieces, ran the autorouter gain, and now this is my final board layout.
Now that I have my board file made, I can open that up directly in bantam tools, the software for our milling machines.
I got it pulled up in bantam, connected my computer to our milling machine, and went through all the necessary steps for getting the machine ready to cut such as homing the axes and setting the material properties.
After things were all set, I ran my first trace cut with a 1/64th inch flat end mill. This went as planned, and the traces looked great after cutting, so I ran another trace cut with a 1/32nd inch flat end mill to get some extra copper material out of the way.
Next, it was time cut the outline. I must have gotten caught up in the moment and missed something while I was working on this because when I ran the outline cut for my board, it started the cut about 10 mm higher on the Y axis than the traces. This meant that all of the traces I just cut were destroyed by a 1/32nd inch end mill tearing through them.
This sucked, but luckily it was a quick fix. I ran another cut of the traces above my failed cut, which looked good once again.
Then I ran another outline cut. This time I was sure to check that everything lined up right before starting it. The cut worked as expected this time, so I took out my board and got ready to start soldering my components onto it.
I really enjoy soldering, so it was fun to do some more of it this week. The soldering went well, and I’ve included a few photos of my progress along the way bellow.
Then, to clean it up and get the extra flux off, I washed the board in acetone. After the cleaning, my board looked great. I forgot to mention this earlier, but to make this board my own I changed the layout of the components and I added in a red LED that turns on when data is being sent through the serial port or when anything is being uploaded.
Programming In Arduino¶
The next thing I did was program it. This week, I decided to program it through both arduino and powershell. I started in arduino by putting the hello.button.45.c code from the lecture notes into a new project, then I changed the processor to an attiny 45 and I changed the clock speed to 8MHz. Once these were both set, I connected my board to my programmer.
Then, I burned the bootloader and uploaded the code to the board.
It uploaded just fine. Now, for the moment of truth, I opened up my serial monitor to see if the code worked. Whenever I pushed the button down, my board sent a “d” to the serial monitor, and whenever I lifted it up, it sent a “u”, for “down” and “up”.
Then, I changed the characters to say “H” and “i”, rather than just “d” and “u”. I know these modifications are incredibly slight, but it’s all that came to mind during the short time I had. With these new changes, it’s sortof like I made my own little hello world.
edit — After talking with my instructor, I’ve realized I didnt really outline what I was learning from the coding I did. The following work up to the Heading, “programing in powershell”, shows what I learned and realized.
One of the things I started to notice and began to apreciate more about coding this week was the ability to define a variable one time in your setup code so that all you have to do later on is reference that variable, not all the info that comes allong with it. A great example of this is the initialization of the pins in the main loop. Pictured below is all of the underlined references to a pre defined variable.
Every single one of these is just a refernece to something up above in the setup. this way, if you have to change something in your code that is used in many different places, all you have to do is change the reference, not all of the individual uses.
This shows the definitions up above in the setup that get referenced many times by the rest of the code.
This is incredibly usefull. I can use this when I work on LED arrays so that rather than individually changing the time between each LED blink by hand, I can define a variable and just change that one variable to change the rest of the times, saving me a bunch of time myself.
Programing in Powershell¶
Next came the slightly more challenging part, doing all of this through powershell. I took the arduino file and changed it into plain C code without the .ino ending, then I got the make file from this week’s lecture notes. I put both of these into their own folder called “Input_Week_Board_Ccode”, then I opened up powershell and typed “cd Input_Week_Board_Ccode”. The picture below also has the .out and .hex files in it because I took the screenshot after finishing programing.
Then I typed “make”, but it didn’t quite work out at first. There was some sort of error with the .hex file.
I went back into the makefile and tried to see what could be causing the issue. For some reason, there was a “;\” after the line that generates the hex code and I think that’s what was causing the issue.
After I deleted both of those characters, I tried it again and this time it worked fine.
Then, I typed, “make program_usbtiny” to upload my code to the board. Thankfully, it all worked as expected.
I tested it out in the serial monitor again just to be sure it was working.
I decided to use the oscilloscope to read the signals as they were sent across the serial monitor. First, I got out our scope and set up the leads in the correct places on my board.
Then, I set the scope trigger to “signal” and pushed down on the button, which sent a “d” to the serial monitor. I saw the series of pulses come up on the screen, and since I had set my bit delay time in my code to 100us, or 1 millisecond, I was able to see that all of the pulses lined up perfectly with the gridlines on the screen, which were spaced at 1ms apart. The image below shows the data for a “d” which is what was sent when I pushed down on the button.
Then, I read the data as I lifted up on the button, which would send a “u” through the serial monitor.
Then I got curious. I wanted to see how the data would change when I sent an “Hi” rather than a “du” from the button. I reprogrammed my board with arduino, then I got it hooked up again to read. When I pushed down on the button this time, it sent a “H” to to the serial monitor, and if you look closely you can see a difference in the length of the pulses from the last ones.
Then I read it again when I lifted up on the button, sending an “i”.
It was really cool to see all of this. When I used the oscilloscope before all I really saw was a simple high to low pulse with intervals of one second, but now I actually got to see what the data for a character looks like going to the serial monitor. It really shows just how much is going on inside of all these complicated electronics, and it makes me realize just how much more there is that I still don’t know.
Here are all of my files from this week.