Corey M. Rice : Fab Academy 2017

Embedded Programming

Learning outcomes:

More Concrete Evidence:

This week was a busy one. It is the end of the quarter at the high school where I teach, so my life is busy in addition to Fab Academy. Grades are due and everyone is a little on edge. Spring break is looming in the building, and it is palpable.

Reading a Data Sheet

Resistors, capacitors and LEDs all have relatively simple datasheets. The MSDS reports for most chemicals are even a relatively short and straightforward read. Although I assume it is only a small number of people who keep either of these on their nightstands. Microcontrollers, on the other hand, have hundreds of pages of data sheet to sift through, because they are such complex devices. All of this complexity despite easily small enough to be carried around on the backs of grasshoppers. There are several important sections in the ATtiny44a datasheet, including: Pin configurations, an Overview, architecture diagrams, information about the memory types, the clock system, power management, interrupts, I/O ports, packaging details and many more sections. The pdf linked here has 27 numbered sections and 2 more, for your enjoyment. Really, there is a lot that needs to be communicated about these devices and it takes that much space to scratch the surface. Luckily, nearly all datasheets (other than the icky old scanned pdf files) are well organized and linked to help you find what you need.

The first things I looked for were the critical stats: What are the pinouts? What is the max voltage? How much current can the chip pass safely?

I know that I need to get better with understanding the memory types on these devices. I have been using Arduinos from time to time, for several years. However, that lovely IDE has never backed me into a corner where I really needed to think about flash vs. EEPROM memory. I hope that I will learn more about those memory types as I expand my horizons with microcontrollers.

Connections and Toolchain

Getting an idea from your brain to a microcontroller requires taking a lot of little steps. First, you need a microcontroller. In my case this is the ATtiny44A that is a part of the ‘Hello World’ board that was designed and made in week 6. Actually, I had to remake that board because my fist go around didn’t make all of the electrical connections that I wanted. I hadn’t even had a way to really test if the board worked, I only knew that I had soldered everything on the right way, and that it looked like it should work.

Then you need ways to physically connect the microcontroller to a computer, from which it can be powered and receive code. I am equipped with the USBtiny fabISP that I had made in week2, an FTDI cable, a USB hub and an AVRISP Mkii (which I bought on Amazon in an attempt to make sure I had at least one working programmer at home).

There is a suite of software packages that need to be installed on a computer as well in order to enable this action. You need drivers for everything. The Atmel Studio or the AVRdude toolchain on my Windows computer, and (I would eventually find) an unaltered installation of Ubuntu on a computer that is easily 10 years old…

Guessing at the Workflow

Many great resources will guide you through the finer points of getting ideas uploaded onto microcontrollers. Some of them are complete solutions like Atmel Studio, which has everything you need bundled into one nice-looking GUI package. Others are the command-line programs that have genuinely unhelpful help screens and essentially require you to already know what you are doing. Given this spectrum of options, I chose to start with the friendly seeming GUI of Atmel Studio 7.

Atmel Studio is clearly very powerful. It has many options and a wealth of training videos that are produced by the company and freely available online. As I was getting oriented with the software, those training videos that seemed so promising often began to feel as though they too were to clarify niche parts of the program rather than to give an easy overview. I even struggled with which type of project to start when attempting to begin coding. Not even considering that my AVRISP Mkii was not recognized by the software. All around frustrating. I struggled with Atmel Studio for several hours, hoping it would not be a dead end, but it ultimately was for me. Sometimes the biggest and best resources can just give too many options for a beginner to deal with. All of this was made even more frustrating by the fact that I was hoping my investment in a commercial programmer would pay off in ease-of-use later.

So next up, Command line on my Windows PC. I do like the command prompt. It makes me feel like I am ‘really computing’ when I use it. I had used Make, and Avrdude before to burn the program onto my USBtiny programmer. I felt confident that I could make it work again, if everything went smoothly. But it didn’t. I had downloaded the files from the week’s notes online, and saved them in a directory. It took me a while to find (in the tutorials) that I really should just rename the makefile and then which flow of command line programs to run. I started where I needed to: run Make in the directory with the makefile and program written in C, but I got an error. Or rather, part of an error. Make generated the out file without hesitation, which I believe is in binary. But I received this error rather than a hex file. Something in my toolchain was amiss. It took me over an hour of trying to decipher the error message, suggestions and help screens that popped up. Eventually I came to realize that this problem may be beyond me right now. I am sure someone who has acquired this ‘deep earth magic’ could easily spot and fix this problem in the toolchain, but I am not there yet.

So, on to the last option. In my basement, there are many things: odd smells, out-of-season decorations, too many tools, and a few old computers. I dusted off one of those computers, because I knew it was a Linux machine. The device itself is easily a decade old, but I tried to breathe new life into it a few years ago by installing Ubuntu. I pretty much hadn’t touched it since, as the installation was more of a test to see that I could do it, rather than a real utilitarian pursuit. In any case, I knew I had something that could at least be a little closer to the device that Neil regularly works from. So I downloaded the echo file and makefile again, putting them in a folder, right on the desktop. Then, through the integrated system toolchain, I just opened up a terminal window and it worked. I compiled the example sketch and then used the make command to upload it through the USBtiny. Echo worked. I ran the amalgam of wires upstairs to use the Arduino serial monitor to see if the echo program functioned properly. It didn’t. The baud rate was off, but I was elated anyway. I knew that when I sent a character, it would respond with unintelligible characters immediately. I knew what to do: a hello world LED.

I googled ‘Arduino in C’ and this blog where someone had written a few example sketches. I had read the data sheet days ago, but knew my LED was plugged into the PB2 pin. I copied the blog’s code and edited it to drive my LED on pin PB2. Quickly, I altered the makefile. Then to compile the code into hex, and upload through the USBtiny. It worked. The LED came on and I had done it. Code I had (at least partially) written was taking an idea from in my head and turning it into physical and observable action in the real world: a blinking LED. It had been several years since I did this for the first time with an Arduino, but the feeling accomplishment this time was even higher.

After recording the video above, I started to document what I was doing. Using Make to compile hex files and upload them to the Microcontroller, no bootloader necessary.

I also started to make derivative copies of the blinking LED program, with alterations to make the blinking faster. I had hopes that I could integrate the button smoothly, but I think that will take more time. Since I had pushed my schedule to the limit this week, what I had completed would have to suffice.

Summarizing a Useful Workflow:

There are many ways to write code and upload it to a microcontroller; however, we will explore the use of Linux here. Linux is used for this workflow, because it works. The AVR microcontroller toolchain is built right into Linux natively, and so it should be easy to access and implement. Other methods (explored above) can be equally successful, but also seem to have more capacity to let you down.

  1. Obtain a microcontroller board that you can be confident has all of the electrical connections that you need, and parts oriented properly.
  2. Obtain a programmer, FTDI cable and any supporting pieces you need to make connections to your computer.
  3. Write the code to drive your microcontroller in whichever language you like. ( I wrote, or edited, code in the C language.)
  4. Get or build a makefile (of that name, no extension) to guide the upcoming compiling of your higher-level code into more machine-friendly binary and hex files.
  5. Open a terminal in the repository that contains both your high-level code (written in step 3) and your makefile (written in step 4) and run Make, with no options. [This should produce two files automatically – one hex file and one out file.]
  6. Run the Make program-usbtiny command, which will actually upload the hex file to the microcontroller and enact the code originally written in a higher-level language. [You may need to change the program command you use, if you are not using the USBtiny ISP that was built in the early weeks of the Fab Academy.]

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

I am happy to report that I found a way to program a chip from the Arduino environment on the last day before the final presentation. You can use an Arduino as an ISP programmer and upload Arduino code directly to the chips from the Arduino IDE. This gives access to the entire Arduino support community for use with a much broader range of chips and boards. The only caveat is that you need to do some hook-up to the Arduino acting as a programmer, and have installed your target chips as ‘boards’ in the Arduino IDE.

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