Building Blocks: The UART

I know these posts aren’t in any kind of logical order, but I figure I should post about what I feel inspired to post about and, eventually, it’ll all be there. So, today I’m going to talk about the UART code I use on the atMega328p to communicate with the WiFly GSX. It is a bit more complex than the very basic tutorials out there, but I suspect it’s not up to professional grade either. I use an interrupt driven transmit/receive with 256byte buffer for each.

The inspiration for this bit of code came from a couple sources. There is a great and simple UART tutorial on Sparkfun that got me started when all other tutorials failed me. Additionally, reading the AVR Freaks forums, I educated myself on more advanced UART techniques including a suggestion by Dean, I believe, to use ring buffers to store data and handle transmitting/receiving the data in interrupt routines.

In my library, I have the following data structures:

  volatile char in[256];
  volatile char out[256];
  volatile uint8_t inptr;
  volatile uint8_t outptr;
  uint8_t  curoutptr;
  uint8_t  curinptr;

and the following routines:

  uart_init();
  uart_tx(char c);
  uart_send_string(const char* s);
  uart_check();
  ISR (USART_RX_vect);
  ISR (USART_UDRE_vect);

In the next few paragraphs, I’ll show you how these are used, but first, let’s take a quick look at the data structures.

Building Blocks: The Microcontroller

As part of the building blocks series, I thought I would share a modular microcontroller design that I came up with over two years ago and that I am using for the scoreboard project. The Arduino craze not yet peaked and I was not fully aware of what it was, however, I did see some value in what they were doing and couldn’t help but allow the Arduino influence my design. Basically I took the shield concept, added a passthrough bus, and threw out the rest. Arduino is beneficial to those that don’t have a Programmer or who are not familiar with C/C++ or assembly. I had both, so I saw Arduino as having way too much circuitry for my tastes. So, what did I do? I built my own. (This is a common theme with me, in case you haven’t noticed.)

What follows is an admittedly lengthy excerpt of a contribution that I made on the Society of Robots website back in 2008, where I first cut my teeth in all things electronics and mechanics. It’s interesting for me to go back and read my thoughts back then.

A Modular PCB Layout

Introduction:
This project started as a result of my frustration and consternation with etching my own PCBs. Now, if I could draw out a board to perfection in Eagle on the first try, I probably wouldn’t have thought of doing this. However, my Eagle skills are somewhat lacking, as are my soldering skills. I needed a simple way for me to avoid having to build and debug large and complex boards for each project on my list. In addition to reducing the risk of me screwing up a large board, I found that it creates a bit of a “plug and play” environment where I can add and remove modules as needed for my various projects. Changing from a robot controller with motor driver and sensors to a temperature sensor with LCD display is as simple as swapping out the modules you need and reflashing the AVR. (I know, I don’t have an LCD module yet, but I will!)

As I took a look at some of the projects I wanted to create, I realized that there was a common basis for these projects; what I will call the AVR baseboard. There was always a socketed AVR (atMega168 for me), a reset button w/ resistor, and a decoupling capacitor. I wondered if I could build a VERY simple AVR baseboard and then just create modules for the functionality I wanted to add to it. Hey! While I’m at it, I could make them all stack together in a nice neat stacking bus arrangement. At first, I thought it was going to be a bit ambitious for someone of my skill level. Well, I did it, it seems to work pretty well, and I want to share it so that I can inspire others and also (selfishly) get some good feedback from the community on improvements, errors, etc. Here’s how it goes.

Form Factor:

First, I decided on a physical form factor. If I was going to connect multiple modules together, it would be nice if they were all of a “standard” size. I picked a 2” by 3” PCB dimension for the AVR baseboard and for a large module. I picked two other sizes for smaller modules, 2”x1.5” and 1”x1.5”. (see the first attached graphic “Module Sizes.png”)

This effectively gives me a full size, half size, and quarter sized modules. It also breaks the AVR baseboard into what I like to call “quadrants”. I’ve labeled the quadrants A, B, C and D. Each of the modules that I’ve built are built specifically for one or more quadrants. You’ll see why when I go into detail on the ISP and Serial modules.

Building Blocks: Overview

Alright, I’ve hinted and even mentioned what all the components are in the scoreboard, but not really in much detail. To supplement my building blocks series of posts, I thought I would put together a simple diagram of how all the different building blocks are connected and with some basic stats for each.

As you can see, there is quite a bit of power distribution throughout the design. This was one of my main focus points because I wanted to make sure the power was distributed in a safe and maintainable manner. The last thing I want is an epic failure during the middle of a game (i.e. flames…).

Let’s see…I’ve done building blocks post on the digits and the SMPS. I think next I’ll discuss some of the code I used on the atMega328p and then perhaps a blog on the battery, battery safety, and power distribution.

I'm Finished! (sort of)

Finished the scoreboard!! I had a week of vacation, so I made a big push to finish. Now I might have time to document the rest of the building blocks.

Building Blocks: Switch Mode Power Supply

I know what you’re thinking…”Wow! This guy must be really smart because he designed a switch mode power supply for his project.” Well, I hate to disappoint, but I’m not really that smart at electronics (that’s why I’m doing this project…to learn!)

The truth is, I was looking at building my own SMPS, but it looked like a chore even considering there are some really easy to use chips like the LM2575. Picky PCB layout problems and the fact that I don’t own an inductor of any kind, really made me think twice about trying. Oh, I designed a SMPS in Eagle, but I have yet to try it because I came up with a…how should I put this…dumb simple, solution. That is, simple enough I can do it and it just works. No fussing around with it.

First, I knew that I needed something to convert from my 11.1V (call it 12V) LiPo battery down to a useful 3.3V. Looking at typical linear voltage regulators, I could see that I would be burning up lots of my battery as heat. In fact, a 12V to 3.3V linear regulator is only about 28% efficient. That’s a deal breaker. This scoreboard needs to be as efficient as possible in the power department because it could be used for hours at a time. Incidentally, during development I was using a 5V LDO regulator and just converting from 12V to 5V caused the regulator to heat up to where it will burn you if you touch it. I don’t want that in my scoreboard box. The LEDs are going to be warm enough. My other option was to look at a SMPS.

Looking up SMPS online, I found that they tend to be about 80 to 90% efficient in the voltage and current ranges that I am expecting. That’s a HUGE improvement. This is when I made the decision to do a SMPS or bust. Little did I know that I actually had a SMPS lurking in my desk drawer that would do the job perfectly. While I was pondering SMPS datasheets, I noticed a car charger from a long defunct cell phone laying on my desk. “Hey!” I said to myself, “that thing converts from 12V car voltage to 5V USB!” My search for a SMPS was over.

Gutting the charger, I found a small circuit with a couple resistors, a diode, an 8 pin unmarked dip, and (the tell tale sign of a SMPS), an inductor. But this SMPS outputs 5V, not 3.3V, which is what I need. Having done a bit of research already, I knew that the voltage on a variable SMPS chip is set with a potential divider. So I set out to recreate the schematic of this simple board. Soon, I had identified the two resistors that create the voltage divider, figured out which one I needed to replace, calculated the new resistor value, and replaced the resistor with an appropriate value for 3.3V output.

Honestly, I didn’t think it could be this simple, but apparently it was. When I powered on the circuit, it measured exactly 3.295V. Sweet!! I had concerns that perhaps this SMPS couldn’t handle the current required for running all my electronics, but now that I have it hooked up I can see that it’s not going to be an issue. In a steady state, my electronics (minus the digits which run on 12V anyway) take anywhere from 30 to 50mA with peaks up to 200mA. The SMPS can handle that, no problem, if it ever charged a phone.

Here’s a pic of my repurposed SMPS.

For those of you that are impeccably observant, you may have noticed that there are two resistors connected together. That’s just me not being able to find a 1000 ohm resistor, so I made one with two 500 ohm resistors. Yeah, okay, it’s not that clean, but it works and I’m all about things that just work.

That’s all for now!

Edit:

I've had a couple comments from folks clarifying the efficiency assumptions that I made in this post.  This inspired me to measure the actual efficiency of the supply in question.  Here are my results:

I attached a 9v source to the input and a purely resistive load of 58 Ohms on the output.

Vin = 9v
Vout = 3.3v
Iin(no load) = 3.6 mA
Iin = 30 mA
Iout = 55 mA

Time to whip out Ohm's Law.  As you can see, the supply consumes 3.6 mA current with no load connected.  Overall, the supply is

(55 * 3.3)/(30 * 9), or around 67% efficient.  Not too bad, considering.

On a positive note, the current that the supply consumes remains constant, so the higher the current, the higher the efficiency (to a point).  At higher current, I suppose this supply could easily reach 75% efficiency.

Thanks for all the comments and keep 'em coming!!

Building Blocks: Anatomy of a Digit

Having already quite a bit of experience with microcontrollers, I decided to tackle the score digits first. I figured that if I could build these, the rest (except for maybe the wireless) would be pretty straight forward. Also, the digit design would be applicable for score digits, the inning digits, and also the balls/strikes/outs display.

My design criteria were as follows:

1. The digits must be easily visible from a distance
2. The digits must be visible in sunlight.
3. I must have dimming control of the digits for night viewing.
4. I need to control all of this from a single microcontroller (atMega168 or similar)

After much research, I found these wonderful chips from TI (TLC5916) and STMicro (STP08CP05). Both are effectively identical. They each have their own value added features (none of which I use), but the basics are the same. They are a 8-bit, constant current, LED driver with cascadable latch registers. Additionally, they work on 3.3V power, which is something I didn’t consider before I started, but is convenient since I’m going to likely have to run the whole thing on 3.3V because of the wireless module I’ve chosen.

These chips are quite simple. There is an SPI input and an SPI output on the chips. From your microcontroller, you start by sending a byte on the SPI peripheral. This shifts bits across the SPI bus and into the shift register on the TLC5916. Then, if you take the Latch Enable pin low, up to 8 LED driver channels will be lit based on the position of the 1 bits in the byte you sent. Cool!

If you send more than one byte, as the second byte is shifted into the first chip, the first byte gets shifted out of the chip to the input of the next chip. This allows me to send an entire string of bytes that represent the values I want to display on the scoreboard. Once I’ve shifted all the bytes, then I take the Latch Enable pin low and the LED driver channels light up all at once. Double cool!

In order for this to work, you have to design your board so that you can easily cascade them. Some pins, SPI in for example, terminate on the chip. Others terminate on the TLC5916, but also are passed on to the next; Latch Enable, for example. Also, the SPI out pins have to be connected to the next as well.

The LED segments are 10mm red ultrabright LEDs, four in series, and powered by a 11.1 LiPo 4000mAh battery (let’s call it 12V for now). I’ve decided to use a bus bar power design for simplicity. All 12V power and ground are derived from these bus bars and are connected to each digit with a 5mm dual screw terminal connector. The electronics are powered by 3.3V coming in on the cascade connectors.

A picture is worth a thousand words (or more), so I’ve added a view of what the Score Digit schematic and layout look like. The schematic is pretty straight forward. I simply copied the sample schematic out of the data sheet and then added in my own values and LED design. Then I added in a SPI/Power/Latch bus design that would enable me to easily cascade the digit modules.

The layout of the PCB is, even now, in a state of flux. Each time I make one of these, I find something I can improve. Mounting holes, copper fill to help with heat dissipation, layout so I can optionally use SMD resistors and capacitors, adjustments to tracks to allow for easier home etching and drilling, thermals on pads, then no thermals on pads (ended up being a bad idea). Here’s the latest version of the layout, and I may yet change it because I have two more of these to make. There is a variant of this module that I will be using for the inning and ball/strike/out display. Essentially it will be the same. I will post this once I’ve made it.

I hope you've enjoyed this segment.  More later!

Building Blocks: Introduction

It’s pretty funny how my neighbors view my different projects. They’re always asking, “so…why don’t you just buy one of those on the internet?”, to which I reply, “none of those on the internet do exactly what I want them to do.”

This project is no different. I wanted an open scoreboard hardware platform that I can control from common wireless devices (mobile phones, netbooks, etc.) I also wanted a scoreboard that didn’t cost me $1000 and that I could actually repair myself. Well, I haven’t exceeded the $1000 mark, but it hasn’t been a cheap project either. Subsequent versions (i.e. those made by fans of the blog) should be significantly cheaper without all the trial and error (and error, and error, etc.)

When I began to plan this project, in earnest, I quickly decided that the best way to pull this off would be to cut the project down into building blocks. Mass produced products benefit from a single monolithic PCB that does everything. For me, that simply isn’t the case. This thing needs to be modular so that I can build the smaller building blocks, test them, and then move on to others. I’m going to detail each building block in a series of posts along with the files I used to create them.

The building blocks I am working on now are score digits, inning digits, balls/strikes/outs, microcontroller, and finally the wireless interface.

I don’t need no stinking drill press!

That’s right. I drill my holes by hand. Yes, I even own a rather large drill press, but I find it easier to achieve the precision I’m looking for with a simple hand drill.

This is one of the 7 segment display boards for the scoreboard. I did the layout in Eagle and then used the toner transfer method to put it on some 4”x6” copper clad I bought on Ebay. I use a solution of diluted HCl and H2O2 as etchant. It works great and is a bit greener than the Ferric Chloride method. Do a search at Instructables. There’s a couple instructables on this method of etching.

Here’s a preview of where I am at right now with the scoreboard. Unfortunately I did not think of blogging my progress until now, so I’ve made some significant progress already. I will try to go back and document most things I have done so far. Stay tuned for that.

Let's Get Started, Shall We?

A few years ago, I realized that there were many things I've always wanted to do and learn, but never took the time.  Some of these things come from as far back as when I was a kid, but I never had the time or the opportunity to pursue them.

So...I took up Snowboarding.  Now, a 38 year old on a snowboard for the first time is a comical thing to see.  After a few years and a couple mishaps where I smashed my knee real good and almost knocked myself out even though I was wearing a helmet (thankfully), I decided that I scratched that itch enough and should move on.

So...I decided to build a robot.  Oh yeah, it was going to do everything and I knew exactly what I wanted to do.  I realized that I knew bupkis about anything to do with electronics and mechanical engineering.  I did know that I have some significant skills as a programmer, so I hoped that would help compensate for my other deficiencies.

In programming, things are on and off, true or false; values are known and don't deviate.  I came to find out that it is not the same in the real world of electronics and mechanics.  No amount of programming prowess was going to compensate for my electronics and mechanical newb-ness.  I was going to have to learn how to reign in an analog world into a digital format that I can work with.

So...I decided to learn electronics.  Digital electronics, at first, because it fits best into my digital view of the world.  I went through the whole breadboard , then toner transfer, etching, and building my own circuits.  I've learned a lot in this journey.

So...I decided to scrap the robot project.  Why?  Well, to be blunt, most robots I saw during my journey in electronics fell short of the expectations I would have for myself.  Some stood out, but it was clear that there was a significant amount of electronics, mechanics, and programming skill behind them that I felt I simply didn't have at this point.  What to do then?

Well, I figured I should hone my electronics skills by building a project of significant complexity in electronics.  Next I should hone my mechanics skills by building a project of significant complexity in mechanics.  For my first project, I decided that I should build an electronic scoreboard for my daughter's softball team.  The beauty of this project is that it involves almost no mechanics whatsoever.  That way my lack of experience with mechanics won't stall the project.

This is where I am today.  Building the scoreboard.  And this blog is my attempt at documenting my successes and my failures.  Along the way, I expect to be able to post valuable information for others to use, and hopefully I can also see some feedback from the community for improvements to my project.

I have many other interests and projects going on, so you may see much more than just the scoreboard on here.  Feel free to enjoy my other ramblings as well.

Thanks for reading!

Ken.