Interface and Application Programming

Write an application that interfaces with an input and/or output device that you made, comparing as many tool options as possible.

Learning outcomes:

• Interpret and implement design and programming protocols to create a Graphic User Interface (GUI).

Have you:

• Described your process using words/images/screenshots
• Explained the GUI that you made and how you did it
• Outlined problems and how you fixed them
• Included original code

Best Laid Plans…

This week’s work felt like it should be an almost ‘easy’ extension of previous week’s work. Surprise: it wasn’t. I had hopes that Python would easily be able to handle the tasks at hand, and that it would work without too much consternation. At the onset, I figured that JavaScript would be a nice secondary toolset to try, but likely not what I would have as my go-to resource for application development. Certainly I knew that I had to finish some of the boards that were left undone from the previous week, so some milling and soldering would need to happen for interfacing. Starting the week, I planned on (1) writing in Python, (2) designing and producing the circuit boards I would need, (3) producing the code for those circuit boards and (4) possibly getting to try using JavaScript if time allowed. Almost none of that happened in order.

Starting with Python

I started where I intended: with Python. Since the ‘print’ function in the example programs don’t use parenthesis, it seemed that Python 2.7 was preferred for Fab Academy. So, I started there. This meant that I had to install that version of Python in my laptop. No problem. Everything went well. I also tried to install pySerial, which seemed to go without a hitch. Then I got to program writing. I looked around the web for a few examples of python programs that could give me a few simple buttons to use for my interface. After a bit of research, I was able to get something up and running using tKinter that had buttons with the names that I wanted. It seemed promising, if still a simplified version of the program it could grow to be. There is something oddly satisfying in taking an idea and turning it into a operable computer program. I had enough code so that buttons could show up. It wasn’t pretty, but it was something. All of my serial communication was just a stub within the program, but it worked up to this point. When I tried to integrate the pySerial parts, things started to break. I received compile error messages that made it look as though I hadn’t installed pySerial, which I had. Even after reinstalling both python and pySerial, I still received these messages. I wasn’t sure what to do, but I was sure that I had to go to bed. The problem would wait for another day.

Switching to JavaScript

Switching to JavaScript was fairly seamless. I remembered that years ago I had don’t Khan Academy’s 'Intro to JS' course, and so JavaScript might be a bit easier than I was imagining. I also knew that I could install the Node.js framework and likely get my serial port up and running. Thinking this may be a workaround to the problems with Python, I gave it a shot. It didn’t take long before I remembered that I had already solved the problem of buttons on a webpage – they are on the left of this very web page. HTML/CSS buttons were a problem I had solved in week 1 of Fab Academy. So I extended this idea. With a little digging around, I figured out how to change a group of buttons into properly sized and stylized inline-block elements. This would give me a visual style to my button interface. I then got to work on the JavaScript.

The JavaScript (and jQuery) seemed like it could serve two purposes: (1) I could use it as a control method for my serial communication and (2) I could use the visual style of the JavaScript-enabled buttons to simulate what should be happening to the LEDs connected over Serial. Purpose 2 meant that I could do most of my development on the computer itself, for almost all of my debugging needs. With a clever implementation of JavaScript functions, I could consolidate the number of times that I need to invoke Serial communication in the code and thus isolate that part of the problem. So this is what I set out to do: solve all of the logic of how the buttons would interact first, then implement all of the serial communication pieces. Separating the problem into manageable parts like this felt critical to success.

Breaking up the process paid off. I was able to figure out how to get all of the JavaScript elements to interact nicely. I even built a button that would turn all of the LEDs on and another that would turn them all off. I tried to make a Marquee function, but it only mostly worked. Mostly, because it went through the flow of a marquee. I could watch it happen through a browser’s developer screens. However, I struggled for a while to try and get the JavaScript to implement some sort of a delay.

Building the Physical Objects Needed

Up to this point, I was still running behind on the networking week’s homework. That did not bode well for a straightforward week. I had developed several boards, and a few of them from the previous week existed, but the festivities surrounding my Physics Students’ graduation from high school really stymied my productivity. Anyway, I was back at it. I began by milling out a proper LCD Control board, which went well. I did decide to ditch a voltage regulator in favor of a solder bridge, but this was an otherwise uneventful construction. I also milled out the LED board that I had been thinking of when designing my JavaScript buttons. Finally, I got to building new circuits. I needed to design a way that I could power my bussed boards and, for the time being, get them attached to the serial communication of a computer. So I designed a very simple connection board. It only included an FTDI hookup, 2x3 AVRISP header and a power indicator LED. I also started to build the networking cable and working though the items of finding the 2x3 pin orientation on each board.

More to come… …must sleep… zzz

The album below will be more fully integrate into the page shortly. (School is about to let out for summer break.)

======================= UPDATE ===============================

Final Solution

I was stuck on this project for a long time. It took me a while to understand how node.js interacts with the website and the board to get everything operational. I wanted to try and do something that didn’t extend too far from the examples, since I anticipated struggling to get this week’s work done in and around school activities. There were three main components to this project: 1) the website 2) the board and 3) the node.js server program.

The Website

The website went through several versions. I based it off the pages that I run on my website. I first wanted to make buttons for each charlieplexed LED. This required me to write and incorporate a JavaScript file and alter the HTML to include these functions. I also used jQuery in my HTML to help the buttons function as they changed states. Figuring out this trick took many hours. I was not experienced with this at all. After this was completed, and I wrote the code for the website side to work I made two key realizations: 1) I needed a separate Serve program to actually send these char command out the USB port and to the board. 2) I could not charlieplex my LEDs and simultaneously have it listen for commands over serial (without Interrupts).

This meant that I redesigned my website. I wanted to make it so that the website mimicked what happened on the board, so I simplified the page to only have the three buttons that controlled the wires. However, I also added six false buttons that would imitate the state of the LEDs on the board. In order to figure out the relationship between the wires and the LEDs I developed a truth table spreadsheet to make sure that I understood the relationships I had developed.

The Board

The board that I used for this week was a derivative of the charlieplexed LED board that I prepared for my outputs week, and anticipated using in the final project [I did not end up using it in the final project.] I built the board to charlieplex, which is an active process. It takes processing power to cycle through all of the LEDs and actively blink them on or off. This means that I could not charlieplex and use the get_char function because it has a delay. I only figured this out after hours of wondering why the board would blink once with my first iteration of code. In response to this limitation, I wrote the code to run the standard get_char function and then turn the three actual control wires on or off. This abandoned the charlieplexing, but could still prove that I was able to meet the goals for the application and interface week. It is worth noting that I did try to invoke an interrupt routine on the ATtiny44 but, under the time constraints, I didn’t want to push my luck.

The Node.js Server Program

The server program was delightfully simple. It was basically just Neil’s example. The only notable exception is that I included an initialization function that would send the ‘a’ command in initialization, to show that the connection was operational. Also, I had to play around within the console, having it print out the address of my board, so that I could include the correct address to connect to. My board insisted on sending a ::ffff:127.0.0.1 client address. I was only able to identify this and change the server program after reading the console log reports.

Final

Altogether, the project worked. This was a major exercise in coding. It took much longer than expected, and the result was not nearly what I thought it would be. However, I am proud of the final product, and you can see it below in operation.

You can see all images (used and unused) from this week's work HERE.