The Delian's Commonwealth

BASPLC2: Instruction Set Design -- Bits and Bytes

Now that we have an idea of what instructions we're going to implement, we have a real challenge in front of us. How do we represent these in memory so that an interpreter can execute them. (Yes, I know I short-circuited some design decisions with this -- we could generate actual machine code for the PLC processor, but we'll go with an interpreter instead, making things a tad simpler and more portable.) I spent a lot of time on the earlier projects trying to figure out what the AB PLC-5 binary representation might be based on the external documentation including instruction size. I still can't figure out how they get some of those things packed so tight. Again, that was a swamp that slowed me way down. Besides, I've done assembly language programming for years and have a pretty good idea of what the trade offs might be.

Trust me, there are trade offs. Lots of them. We'll start with the size of the address space. How big do we make it? A larger address space means (generally) bigger instructions to reference those addresses. A small address space can make programming a real challenge. Back in the day, I worked on an IBM S/360 Model 22 with a whopping 64K of memory -- that was enough to run the business office of a major university, but dang was it cramped. Fortunately, PLC programs tend to be on the smaller size; we're not trying to program IBM's Watson into this. The word size of our PLC is 16 bits, to be consistent with many of the PLCs out there, which gives us a 64K address space. Many (most) of those put data and program memory in that same space; one of the design criteria for BASPLC2 is that we'll keep them separate, so that gives us a full 64K for data and, effectively, unlimited program space. That should be enough for any reasonable program. The PLC-5 allows up to 1000 files in the data space, just so that we don't waste bits, we'll allow 2¹² (4096 files.) While that's overkill, the next 4-bit increment down would be 2⁸ (256) which is pushing things a bit too small.

We could go for extreme efficiency in program size by being clever in how we encode instructions and addresses. Since we've just given ourselves a lot of program space (limited to the available physical or virtual memory of the host processor), we don't need to worry too much about that. I actually started with an implementation that broke an instruction down to the nybble (4-bit unit) basis, but found that decoding that was a serious pain and added complexity where it wasn't necessary. There's a little bit of that left over, but it's now constrained. So, how do we represent the instructions? Let's start with the most complex part, addresses and literals. These are the operands for the instructions and are the most complex to implement.

There are several "addressing modes" available in PLCs. First, we could have a literal value, usually a 16-bit integer or 32-bit float. Addresses can be much more complex, though. First off, the data space is divided into files, each file being a collection of elements of the same type. So, there is an integer file that is all integers, a bit file that is all bits, a timer file that is all timers and so forth. We can have multiples of each type (except for input and output) but the data type within a file is consistent. So, we'll address a file with a type and number like this: "B3" or "N7", representing file #3 which is binary and file #7 which is integer. "T4" is a file of timers. Now, we'd like to address a single word or element in a file. "B3:2" is the 3rd word (zero based) in file B3. "T4:5" is the 6th timer in that timer file. Now we have a bit of a split between the scalar types like binary and integer and the "structure" types like timers and counters.

For scalar types we frequently want to address a single bit. This is especially true for input, output and binary files and occasionally true for integer. If you're playing with bits in a float, good luck to you. To address a bit, we add a bit number, "B3:2/7". This is now the eighth bit in the third word of the binary file. Note that there's a little confusion at times, because sometimes that bit number is address in octal (base 8) and sometimes in base 10. That means that "11" could mean decimal 9 (in octal) or decimal 11. In any case, there are 16 bits in each word.

For structured types, we need to be able to address both bits and certain larger elements, such as the accumulated count in a counter. We use a different notation for this. "T4:5.EN" is the enabled bit for the timer, while "C5:2.ACC" is the accumulator for the counter, a 16-bit integer word. It's important, obviously, that the symbol used match the context -- having an XIC instruction referencing T4:5.EN is fine, but referencing C5:2.ACC is not.

So far, so good. We've got literal, file, word, bit and field addressing. These are all "immediate." But what if I want to use one word to indicate what word in another file should be referenced -- this comes into play a lot when you have looping. For that, we have "indirect" addressing. Just to make things entertaining, we can make the file number, element number and bit number indirect (although there are issues making timer, counter and control element numbers indirect -- some PLCs forbid this.) In a ladder logic program, we use a bracket notation to indicate this.  "B[N7:2]:2/5" is the sixth bit, of the third word of the file whose number is stored in N7:2. Which had darn well better reference a binary file or you're messed up. Indirect addressing has its drawbacks. "B3:[N7:4]/2" references the third bit an a word whose number is stored in N7:4 in the file B3. N7:4 had better not be negative or equal to the size of B3 or greater. More things to watch out for in indexed addressing. We can do the same thing with a bit number, where the value of the indirect must be between 0 and 15. Note that we cannot do that with the fields of a structured type. At best, we can make the file or element number indirect. If we really want to make things hard to debug, we can combine any and all of these. "B[N7:2]:[N7:4]/[N7:6]" is a legitimate reference, but figuring out what it's looking at is not so much fun.

Finally, we have "indexed" addressing. In some situations, this is a rough equivalent to an indirect element address where there is a special value used for the indirect; this value comes from the status file. "#B3:0/5" would be the word in B3 addressed by this special index in the status file. So, roughly "B3:[S2:17]/5". I should note that the index register doesn't exist in the Micrologix series of PLCs, so it clearly wasn't that useful. The syntax remains, though, for some instructions that start in a certain place and cover a set of elements. That's just syntactic sugar and doesn't even enter into the binary form of the address. Although I doubt that I'll ever implement actual indexing, I'll leave space for it in the design.

Now, what do we do with this. We'll apply a few design requirements and see what comes out. First, we want this to be compact. Second, easily decoded. Some expansion room would be a nice-to-have. We'll use a 4-bit type code (giving us 16 possible types) and then fill in the rest as needed. The whole result will be byte-aligned although we will have some nybble-alignment within an address. The following picture shows what I propose. (Click to embiggen; you'll still need a magnifying glass, but it's slightly better.)

When we compile this, we'll turn all direct element references into absolute words. That is, the offset of the start of the element from the beginning of the data space. Of course, this will depend on the size of each file, but it's easy to calculate during compilation and very easy to use in the interpreter. An indirect reference then contains an absolute reference. For instance, "B3:[N:7]" will have the "N:7" compiled as an absolute offset in the data space where we get the indirect value, while the B3 part is compiled as a file number. We have to add a fudge factor for structured types since the element number references a block of 3 words and we want one specific word within that. If you look at the "TF:[TF:E]" line in the table, you'll see how we encode something like "B3:[N:7]" or "T4:[N:7].ACC".

(Edit: Ooops... I stopped before I finished the design!)

Now let's move on to the instructions themselves. As I said earlier, I tried a nybble-based approach with the most common instructions requiring just one nybble of opcode, some taking 2, some taking 3 and some taking 4. Nice for packing, not so nice for unpacking. Really not necessary, either. A single byte would give us 256 instructions. The first two phases are just about 50 instructions. If we need more than 256 distinct instructions then we're really, really, really over-designing something. The only extra stuff we need for the first two phases are a nybble of zeros for the SBR and RET instruction parameter counts and two nybbles of zero for the SBR instruction (input and output parameters.) That's it. One byte and a touch extra is all we need.

If you've got questions, ask them in the comments. I'll go into more detail as required, including examples.

BASPLC2: Instruction Set Design

So much for my "roll"... I've actually been working on the project and just skipped blogging so I'll do a little bit of catch up today.

One of the things that bogged the original project down was the requirement to slavishly recreate all of the PLC-5 instructions and architecture. That's a total dead-end. Far better to get something useful implemented first and then add instructions as needed. Well apply the Pareto Principle (aka the "80/20" rule) and look at the 20% or so of the instructions that are used the most. We're helped by this in looking at smaller and simpler PLCs -- what instructions survive the limitations of a smaller system and what instructions are discarded? More experience in coding actual applications helps as well. With a few notable exceptions, the instructions I've chosen to support first are all of the ones that I've used recently.

Before we dive into that entirely, a brief aside about data types. The types that seem to be common to most PLCs are: Input and Output bit maps, Bit, Integer (16-bit) and Float. Timers and Counters as well. After that come ASCII data and Control types. More and more systems seem to have 32-bit integers as well. For the first round, we'll implement everything in that list up to Counters -- we really don't need Float just yet because I left the most useful instructions out, but implementing the type helps get things rolling.

Phase 1 Instructions

Back to the instructions: First, and foremost, are the basic bit instructions. XIO, XIC and OTE. (I'm going to assume that my readers have a basic knowledge of PLC instructions -- if you don't, then there are a lot of reasonably good references out there. I'm going to add the latching output instructions, OTL and OTU although I will likely never use them -- they're dangerous. Hmmm, maybe I need to write my own instruction descriptions just to have the chance to explain that one. One-shots, ONS are very useful and I'll add OSR and OSF as well, just for completeness.

Naturally, we're going to need to support an OR operation, since without it, all we can do is AND and that really won't be useful. In ladder logic terms, an OR operation is a "branch." The instructions for these aren't as explicit in a graphical interface, but when converting a program to some binary form, they need to be there. Internally, we'll call these BRS (BRanch Start), BRN (BRanch Next) and BRE (BRanch End.)

We now move on to the timer instructions. There are three common instructions, TON (Timer ON), TOF (Timer OFf) and RTO (Retentive Timer On.) Although I've only needed to use TON, both TOF and RTO are slight variations so it makes sense to just implement them all at one time.

Counters are very straight-forward, CTU (CounT Up) and CTD (CounT Down.) They're also extremely useful so they get put on the list. To support both timers and counters, we add the RES (RESet) instruction.

Now we'll add a few instructions to round out the first phase. END is necessary, since every ladder file has one at the bottom. TND (Temporary eND) is mildly useful in debugging and not much extra effort, so it gets tossed in the bag. AFI (always false) is also useful in debugging (ladder rungs are true at the start.) Good programming practice often splits a program into multiple files, so we need some subroutine support. We'll implement SBR, JSR and RET, although without parameter support. That forces us into using globals to communicate parameters, which is a bad practice in general, but actual parameter support can be a challenge so we'll defer that and rely on the globals.

One other useful instruction, especially when dealing with initializing and testing timers and counters is MOV (MOVe.) Consistent with the data type support, it'll allow conversion between integer and float as well as supporting literal values.

Finally, like the branches, we need some internal instructions for the binary form so that the interpreter knows where it is.  SOR (Start Of Rung) and EOR (End Of Rung) are all that we need.

Phase 2 Instructions

Phase 2 will round out the collection of "most useful" instructions. As I've been implementing, I've regretted not putting a couple of these into Phase 1, but I'm going to stick with my initial plan.

First we have some basic arithmetic. ADD, SUB, MUL, DIV, SQR (SQuare Root), NEG (NEGate), and CLR (CLeaR.) More complex, but still very useful are SCL (SCaLe) and SCP (SCale with Parameters.) These allow us to convert raw sensor input into something more useful in a program; in part, that gives us some independence from the actual sensors used, meaning that if we change a sensor, we don't have to reprogram the entire thing!

Along with arithmetic, some Boolean logic will help (it can be done in the ladder logic but that can get very messy.) AND, OR, XOR, and NOT are in this set.

Comparison is important. How can we tell if our tank is too full if we can't check the level against some parameter? For this phase, we'll do EQU, NEQ, GRT, GEQ, LES, and LEQ.

Finally, a couple of useful instructions for setting/copying values. COP (Copy) and FLL (Fill.) Although these are "file" instructions, they don't need the Control data type. That one becomes useful much later.

Phase 3 and Beyond!

We'll see how things develop beyond this. There's a rich set of possible instructions there, but implementation from here on out is going to depend on need. Assuming I can get this thing up and running, and connected to something useful, we'll see what's required.

Next up: Binary representations of the instruction set.

BASPLC2: Hardware

I'm on a roll, so I'll continue blogging this morning; it's amazing what you can accomplish when you're avoiding taking an online quiz for a class!

In the last post, I talked about some of the requirements for this project. One of them was to use something bigger than an 8-bit MCU and another was to use some COTS hardware rather than building it from scratch. If I were doing this part under systems engineering best practices, I'd go through a trade study by first developing more detailed requirements and then evaluating possible solutions according to those requirements. I'm going to take a bit of a shortcut through this process.

I started with some minimum requirements: 32-bit processor, internal FPU and a moderate amount of memory. For a PLC interpreter and PLC program that's only going to be about 300K; anything above that is gravy. With that in mind, I started looking through the Microchip (fka ATmel) offerings. I have been happy with their chips and decided to start with a known reliable vendor. I quickly latched on the "Xplained" series of prototyping boards. Although a bit of over-kill, I settled on the SAMA5D3 Xplained board. The A5D36 process certainly meets any speed and functionality needs that I have. It carries 256MB of flash storage and 256MB of DDR2 RAM giving lots of spare space. It also supports the Arduino R3 form factor, meaning that expansion boards are available. Some care has to be taken since the bulk of Arduino boards run at 5v and the SAMA5D3 runs at 3.3v -- don't want to fry the processor. It's got a lot of features that I likely won't need, but better to have too much available than too little. There are two Ethernet ports, three USB ports and slots for SD (and microSD) cards. The latter are useful for things I don't want to keep in flash memory. You can also use the SD slot to add a Wi-Fi card to the board, although a shield would probably work as well.

There is a connector for a 24-bit touch screen. That would make a very nice control panel for the PLC and it might even be able to double as an HMI for the PLC programs. That's a bit of a stretch so the screen may remain unconnected unless it could work as part of the Linux console when I'm debugging.

The board comes loaded with Linux distribution customized for the platform. Linux is my choice for starting this project although there are some RTOS ports such as NuttX that can run on it as well. Once I have a working version of this, I'll try switching to the RTOS in order to get more reliable performance out of it. One of the requirements for a working PLC is consistent execution times and that's not always possible with a more sophisticated OS.

I haven't made any final decisions on shields/extensions for this yet. I do have a SparkFun ProtoShield that I'll populate with some LEDs and buttons as a development tool. A quick survey of what else is available brings up the AdaFruit Motorshield which can drive electric motors as well as servos and steppers. There are a lot of sensor and relay boards that use the form factor as well, so I should be able to select a couple in order to implement my PLC use case. I'll talk about that once I have enough PLC to make it work.

So, an order was sent off to Digi-Key for the Xplained board and the ProtoShield. I did order a nice touch screen to go with it, but probably won't install that right away.

Animatronic Eyes

Here's another little project that I completed. I've always been interested in animatronics and found this course at the Stan Winston School. It combines some interesting animatronics with 3D printing. That last bit was the big draw for me because I've got limited fabrication capabilities but do have a workable 3D printer.

Overall, the project went well and I learned a great deal. Some of the info in the course video was out of date, so there were some challenges in finding replacements. Here are just a few:

1. The recommended CAD software was not available and the slightly higher version was not easy to use. Instead I got a student copy of Audodesk Fusion 360 (yay for being in a master's program.) Although it took a little getting used to, it ended up being perfect for the project. I had tried Google SketchUp but there were too many issues (like, how do you draw two concentric circles?) I've used OpenSCAD in the past, so CSG (Constructive Solid Geometry) is very familiar -- it's just a different interface.
2. A number of the parts are no longer made. There were some linkages that were from an obsolete helicopter model. I bought a couple of them off of the 'net, but as far as I know, those were the very last ones. It turned out that there were some problems attaching them to the servos that I chose, so I ended up with a different set of linkages in any case.
3. The project calls for some cable tubing -- again, this was hard to find without the cable inside and I didn't need that. Thinking about it, the cable tubing was just about the same as the PTFE tubing used in 3D printers. The 3D printers use a 2mm ID but the tubing is easily available in 1mm ID, so that's what I used.
4. The recommended servos are very expensive ($50 each, meaning a $300 project right there.) I found some smaller servos from Pololu that seem to do the job. They have plastic gears rather than metal, meaning that they're less reliable but this is a hobby project, not a production animatronic.
5. The recommended setup is for remote controlled puppetry. Besides being expensive ($700 controller), I'm more interested in programmed animatronics. I got a USB-connected driver from Pololu and ran it from their software. I have a demo of Visual Show Animation which I'll use to drive this when I come back to the project.
6. One piece of good news: The brass balls used as pivots were very easy to find, despite what the instructor said. A quick search on Amazon found them. They need a bit of polishing to be really useful, but they're fine as-is for an initial pass.
7. Another bit of good news: I found some excellent irises to use for the eyes by searching for steampunk/doll parts on Etsy.

Design and fabrication of the parts was fairly easy. I prefer to work with metric parts (having a good collection of metric cap screws and related hardware) so I converted the project to metric. (As an aside, there's a great source of metric fasteners at Mr. Metric -- they sell in small quantities, making them ideal for hobby work.) The course doesn't talk much about designing for 3D fabrication and so I had to tweak some of the parts to get them to build properly. One of the big problems that I had was trying to cut threads in the parts. I'm using PLA and it's just a little too soft to do reliably. If I redo this, I'll try ABS or PETG. ABS is problematic because I don't have great ventilation in my workspace. In any case, I was able to get the threading to work in most situations and just resorted to some cyanoacrylate glue to fix problem spots.

My one significant failure was trying to power this thing. The servos can't run off of the USB power from the computer so they need a separate supply. I got a small battery pack that worked fine, but I had wanted to make it work from a wall-wart. For some reason, the Pololu power regulator couldn't deliver enough current to move the servos. I stayed with the battery pack but will have to revisit this in the future.

This is a short video that I took of the finished project.

Zane and I have been talking about turning this into an art installation, with mouths as well. Zane does great masks so we can put faces on the animatronics.

BASPLC2

To start with, this project should probably be called "BASPLC3" because this is my 3rd attempt at building a PLC. Here's a bit of history:

PLC5Sim: This was a software-only simulator for the Allen-Bradley PLC5 family. It included not only an emulator but a GUI (based on Eclipse RCP) for building ladder programs. I learned a lot about the PLC instruction set and architecture doing that project. I got it to the point of implementing 90% of the PLC5 instruction set and it would run ladder programs reliably. It bogged down as I tried to emulate the somewhat complex PLC5 I/O model and modules; there are something like 24 different flavors of processor alone. The whole project was over-complicated because I tried to stick very closely to the PLC5 design. Lesson learned: Keep it simple and build the complexity later. Some portions of this project will likely reappear in BASPLC2.

BASPLC: You can read about that by using the BASPLC category on this blog. This was an attempt to build custom hardware using microcontrollers (MCUs) and related chips. On the plus side, this was a great learning experience: 8-bit MCUs, SPI, I2C, CANbus, and a few other driver chips, not to mention Eagle for developing boards. That latter took me back to my days at CADAM working on one of the very first commercial CAD/CAM systems. What killed that project was a combination of distractions ("Squirrel -- I mean 3D printing!") and over-design (again!) I still had the PLC5 model in my head and that affected how I looked at things. For instance, the idea that any peripheral modules had to be physically separated led to designing a bus protocol based on CANbus that would emulate the protocol used by the PLC5. I also ran into some serious limitations trying to use an 8-bit MCU for the main controller. The lack of floating point was one problem (solved by adding a separate FPU) and the other was limited RAM. Some of the ATmel (now Microchip) MCUs can have outboard memory but that was moving beyond my hardware design skills.

So, after a long break, I'm back with BASPLC2. I hope to avoid the pitfalls of the previous projects; of course, there will be plenty of opportunity for finding new ones! Here are some basic concepts/requirements:

1. Use COTS (Commercial Off The Shelf) hardware wherever possible.
   1. Probably 32-bit MPUs such as AVR from Microchip or ARM from a number of manufacturers;
   2. Prototype boards with these chips, along the lines of Raspberry Pi or Arduino;
   3. Standard extension interfaces like the Arduino R3 shield stacking model.
2. Simplify the instruction set.
   1. Start with some basic instructions and leave room for expansion;
   2. Take a phased approach to implementation.
3. Simplify the configuration.
   1. Avoid the "multiple flavors" that over-complicated PLC5Sim tremendously;
   2. Use an I/O model closer to the lower-end PLCs on the market; for instance, the MicroLogix series.

I think that's enough to get us started. As I go along, I'll try to apply some of the systems engineering and program management principles that I've been learning as part of my MS program. The trick there is to not over do it on a small personal project. That'll just bog things down even more.

Blog Redux

Wow. It's been 4 years since I posted. A lot has happened in that time. I'll give some updates and then talk about a new project.

When I left off, I was trying to get the CAN bus board working for my BASPLC project. That project stalled in part due to some frustrations getting the board to work. Even after the patches that I mentioned, I had trouble with the software. Another thing that stalled BASPLC was a major distraction. When I was making the display board I realized that I needed a jig of some kind to make the LEDs line up neatly. That and there was so much bleed-over between the LEDs, I needed them to be isolated from each other. How to do that? I know, 3D printing. Thus was another hobby born. I'll chronicle my thrills with that one in another post.

Work and life intervened somewhere in there and I only got some small projects done, mostly a few 3D printed things. I did get some construction plans for a Walt Disney World attraction and tried to 3D model it. OpenSCAD worked fairly well, but there's no way to decorate. Blender is terrible for architectural type stuff and so I tried moving data from one platform to the other. That didn't work nearly as well as I would have liked. I'll have to go back and continue the OpenSCAD design work and see if there are new 3rd party transfer tools.

What else? I took a few classes on Udemy in PLC programming. These helped fill some gaps in my self-teaching, especially around some best practices. I'm still in the middle of the PLC III course, which covers SCADA and HMI. PLC IV goes outside of the Allen Bradley/Rockwell PLCs so that should be interesting, too.

Speaking of education, I'm back in school, formally. For a bunch of reasons, I've enrolled in UCLA's Engineering MS Online program studying Engineering Management. Some of this is just because I've always been frustrated that I didn't have an advanced degree. I also want to open up some more job opportunities. It helped that having both boys in school inspired me to give it a shot. There are some things that I love about this program and a few things that I don't like. The teachers have either been fantastic or terrible and there's some disorganization in the department. One surprise: I took ENGR 200, "Systems Engineering" and discovered that I'm a systems engineer. All through the class I was saying to myself "wait, I have to do that in my job." It was just a matter of terminology; what I call a "Software Architect" is really a systems engineer. I kinda regret not taking the SE specialization, but I may have a chance for at least one elective that I can take, so I'll look at the choices there.

On to the new (old, really) project: I had applied for a job that I really want, but have been told that they want people with embedded systems experience and not application development. Fair enough, my resume doesn't have a lot of embedded experience and I don't have concrete examples, despite work like the BASPLC. So, what can I do? I'm going to revive BASPLC but take a very different approach to developing it, concentrating on the software and not the hardware. More to follow -- that is, unless I get distracted by something new and shiny!

BASPLC: CAN Communications

Early on in this project I decided to use the CAN bus for communications between modules. I'm still not thrilled by that one but for the reasons cited earlier, I'm sticking with it.

One of the problems that I have with the CAN bus is that it uses DB-9 connectors, which are expensive. I'm not building a real industrial product here, so the DB-9 is a bit of over-kill. For this prototype, I'm going to substitute an RJ-45 connector, so that I can use CAT-5 cabling. I've got a bunch of that stuff, and tooling from an old job to make even more.

One of the features of the CAN bus is that it carries power along with signal. We can do the same with the CAT-5 cabling, modeling it after Power over Ethernet. I'm modeling my connections on the IEEE 802.3af mode B (10/100 with DC on spares.)

Since power is (potentially) coming in via the CAN bus, I'm also making the bus card the power entry point for the whole system. This means a 12v jack and power regulating components.  Not being very skilled at analog circuit design, I borrowed liberally from Spark Fun's breadboard power supply.

The design of the CAN bus portion was pretty straight forward. I'm using the Microchip 2515 controller and 2515 transciever. There are a number of example circuits out there. The MCP controller uses SPI to talk to an MCU. For an MCU, I'm going with the ATmega328P. The ATtiny84 is just a bit too tiny to handle working as an SPI master (talking to the MCP2515) as well as a slave (talking to the module's controller board.) The ATmega328P is a bit big for our needs, but if we want to shave a few pennies off of the cost, it can be replaced with a 16K or 8K version. Unlike the front panel board, we'll be running this one at 16Mhz using a crystal oscillator.

Here's the schematic: Download Plc_comm_can_v10a

To test this out, I built two of them on the breadboard and wired them together. The test and debug phase was more than a little frustrating. Some of the problems:

• 16Mhz is too close to the logic analyzer's maximum sampling rate of 24Mhz. I'm not spending thousands of dollars on a more heavy duty analyzier. I got useful information out but some times it wasn't clear whether what I saw was a real problem or an artefact of the sampling issues;
• The logic analyzer's CAN protocol interpreter blew up several times. Because of problems in getting the bus frequency right (see below), it wasn't giving good information. Once I got the bus frequency right, it did work.
• I'm still not sure what the actual clock speed in the MCU is. Although I've got a 16Mhz crystal and turned off the divide-by-8 mode, it still seemed to be running at 4Mhz. Added to this, it was very difficult to get the right parameters for the MCP2515 to produce the bus speed that I wanted (about 125Khz.)
• I originally put in a couple of LEDs on the transmit and receive data lines between the MCP2515 and the MCP2551. The problem with that is that the bus is normally in the high state so they were on all the time. The bus frequency is fast enough that they didn't really flicker much when active, so I removed them.
• On the prototype, I connected one of my front panel boards to provide output for debugging. It shared the same SPI bus as the MCP2515, with a separate SS line. I found out that the front panel board wasn't putting MISO into the high impedance state as it should, so it was preventing the MCP2515 from working. I couldn't get the software right for that (it still has issues), so I just disconnected the MISO line from the front panel.

The software for this provided more than a few challenges. First, the ATmega328P has two interfaces capable of supporting SPI. There's an SPI interface as well as a USART. The former shares pins with the ICSP interface, so I kept that one as the slave side. (Note: That hasn't been tested yet.) The USART is master-only, so that's perfect for talking to the MCP2515. The USI-based SPI that I put together for the front panel wasn't suitable, so I had to write a new SPI package. I'll cover this in another post, but using C++ inheritance, I'm able to deal with multiple SPI implementations with a few simple interfaces.

The first beneficiary of this SPI package is the MCP2515 driver. The architecture of that one is a subject for a post on its own.

Once I got my two prototypes up and talking to each other, I laid out and ordered a set of boards. As of today, I have the boards and have populated two of them, but haven't done much in the way of debugging. Amongh the goofs here, I forgot to order one part (a resettable fuse for the power supply) and so I don't have a good way to test them. Another goof: While I realized that with SMD components I would need headers for testing, I left off a header for the RESET line and one for GND. I'll probably have to greenwire these or only test connected to another board that has these.  A third goof: My components are a bit too close together. Trying to solder them is awkward and trying to do repairs once everything is in place is even more difficult. Ah well, this is a learning process. I can design software so that it's maintainable but I don't have the skills yet for hardware.

Surface Mount Technology

(I swear I wrote this post a couple of weeks ago but it seems to have gotten lost in the ether.)

The first board using Plated Through-Hole (PTH) technology worked ok. One of the down sides to PTH is the amount of real estate all of the components occupy. I'm trying to keep costs down but PTH makes the boards bigger than they really have to be. The alternative is using Surface Mount Technology (SMT or SMD for "Devices".)

Just about any electronic device you find today was built using surface mount components. There's lots of commercial equipment for doing this, so-called Pick and Place machines among them. Sadly, the cost is prohibitive for the amateur. We're stuck trying to solder tiny parts. And by tiny, I mean 0.8mm x 0.5mm tiny. Or even 0.6mm x 0.4mm and smaller. Some ICs have leads 0.8 or even 0.5mm apart. The thought of working with tolerances that small is daunting.

Scary as it is, I decided to give it a try. In order to learn how to do this, I turned to the folks at Spark Fun. They've got a surface mount version of their Simon Says kit. I'd gotten the PTH version of the kit for my nephew and we had fun building it together, so I knew that the quality of their kits was good. Realizing that my ancient Radio Shack soldering iron wasn't going to work, I also invested in Spark Fun's variable temperature soldering iron. I couldn't quite justify the cost of the Hakko.

The Simon Says kit has a good selection of parts, from a large buzzer, with big tabs that have to be soldered to some 0805 resistors and capacitors and an ATmega328P in the TFQP package (there are those 0.8mm lead spacings!) As with the PTH version, the instructions are very clear, taking you step by step through the process.

Despite the good instructions, I went to the 'net to look up SMD soldering techniques. It was very interesting to see the number of "correct" approaches to dealing with ICs in particular. Some people use a very fine tip and solder each lead. Others will run a bead of solder across the leads. Still others use some solder wick to wipe solder across the leads. Since building this kit, I've soldered a dozen or so ICs and still don't have a technique that I like.

No matter what you do, though, you're going to end up with solder bridges all over the place. This means it's time for solder wick. This is some copper webbing coated with flux -- you place it over the bridge, heat it and capilary action lets the wick soak up the excess solder. This gave me no end of grief the first time out. Either it wouldn't absorb the solder, or the wick ended up soldered to the board! It didn't help much that copper conducts heat very nicely so holding the wick close to the work area becomes uncomfortable very quickly. I suspect that part of my problem was some old wick that had become corroded and the flux evaporated. I'm still using that same stuff but I've leard to coat it with some more flux before using.

Flux. A liquid or semi-solid that helps the solder flow. When I built the kit, I didn't have any flux and that made life much more difficult. Since then I've gotten a flux pen and some "tacky flux" from Chip Quik. They advertise it as being used for rework (de-soldering) but it works pretty well for the inital stuff as well. One of the down sides of using flux is that the stuff is sticky and challenging to remove.

Back to the kit: The instructions start simply with some of the larger components and then move on to the ATmega328P. Everything went well except for the 328P, due to the bridging/solder wick problems. I must have reheated the leads on that chip 20 times before everything looked clean. I was certain that I'd baked the chip into oblivion.

Testing proved me wrong! All of the lights flashed when I switched it on and it happily played Simon Says. The only thing wrong was that it was silent. Looking at the various connections (there's a mute switch), I found that one of the first things I soldered, the buzzer, had a bad joint. The biggest, most obvious solder pad on the whole board is the one I got wrong! Resoldering that one and everything works like a charm.

There is a nother surface mount technique that involves using solder paste and a mask. You squeegee paste onto the pads and then stick the parts down and bake the whole thing. The only problem with this technique is getting the mask. Spark Fun sell a version of Simon Says that uses this technology, but when I looked into it for my own boards I found that the masks can be very, very expensive ($100/per.) There are cutting machines that are somewhat reasonably priced that you can use to make a vinyl mask, but I can't justify $800-$1600 for one of those right now. I'd rather spend the money on a 3D printer. (Hmmmm... I wonder if I could print a mask?)

All in all, I think I like the surface mount approach. The kit provided a good introduction and I've since done several boards, each one a little better than the last.

The Agony and the Exstacy of Systems Programming

Via David at Popehat comes this piece by a researcher at Microsoft. It truly resonated with me. I've lived that kind of life since I started in this business. Systems programming on an IBM S/360 model 25 in 1973 for starters. I've worked at the hardware level and the few layers above it. Working in pointer-less, garbage-collected languages can be fun, but the challenge of debugging something that trashes your entire system and renders your debugger useless is a tremendous thrill. At least, that's what it is when you finish. Working on it can be ulcer-producing.

I missed working in that kind of environment so much that I've stepped back into it with my BASPLC project. What Mickens describes is what I missed about systems programming.

BASPLC: First PC Board

I'm going to skip over some of the prototyping and code for the front panel and move on to making the PC board. Many (many!) years ago, I tried making PC boards using etch-resistant tape and dry transfer markings but the results were, to say the least, amateurish. Things have improved dramatically since I was a teen-ager.

Some time ago I posted the rev B schematic. We're now up to rev D for the front panel. I've also rendered it as a board, using Eagle.

Download Plc_fp1_v10d

Download Plc_fp1_v10d_brd

I was going to use SparkFun's service for manufacturing, but right when I was ready, they sold that business to OSH Park. Submitting the board to OSH Park was easy (once I worked through some issues with the silk screen overlapping the solder mask.) Wait a couple of weeks and, yay!, three copies of the board arrive.

They look corre... oh crud, I put the board name in the top copper layer, but reversed. I meant to put it in the bottom one. Gotta be a bit more careful about this.

Next step is to populate the boards. Since I'm using through-hole for everything, that's not a very tough job. Until I got to the square RG LEDs. Getting them to line up square and even is a major pain. In the future, I'll need some kind of jig to hold them in place.

Time to test. First, I tried loading the stand-alone test driver, but AVRdude is complaining that it can't talk to the board. Double-crud. It turns out that when I first designed the board, I put the programming/bus header on the bottom, along with the LEDs and the reset button. But then I realized that the header really should be on the top with the rest of the componets. That way, the header is not forcing the LEDs further from the outside of the case than necessary. I hadn't flipped the header back to the top in the board design, so I had to un-solder it and put it on the bottom with the LEDs. I ended up having to destroy the header and replace it with a new one.

Ok, with the header on the right side, AVRdude is happy and the self-test loads. It even works! Woo hoo! The next step is to try driving it from another MCU. I put another ATtiny84 on the breadboard and hooked it up. After some struggles with the driver software, both on the FP and on the test driver it works!

The top:

The bottom:
(click to embiggen.)

One physicial design issue (two, really): The RGB LEDs are very bright, so I probably need to change the current resistor on the TI5916 from 1K to something else. In a related issue, the square RG LEDs are close enough together, and dim enough, that they bleed into each other. I have to double-check but I think that the resistor on the MAX7219 is as high as I can go for these LEDs. What would really help would be some kind of bezel that isolates the bulbs. That would probably be able to serve as the soldering jig as well. 3D printer, anyone? Time to re-learn Blender!

Other problems: Space is tight so attaching logic analyzer leads to the ATtiny84 is a pain. The ATtiny84 doesn't have on-board debugging capabilities so debugging consists of monitoring the data pins. There are a couple of spare data pins and I can wiggle those at various points in the program. What I really need, though, are some header pins that I can easily attach the logic analyzer to.

I'd like to reduce the size of this board a bit. It's 1.5 inches wide and I'd like to get it down to closer to an inch, and perhaps a tad shorter as well. That means using SMD components and learning how to solder those. SparkFun has an SMD Simon kit that I'll try.

So, the next version of this board will:

1. Use SMD components;
2. Put the header on the top, LEDs and reset switch on the bottom;
3. Use revised current resistors for the LEDs;
4. Include pins for testing;
5. Incorporate a bezel.

All-in-all, though, I'm pretty happy with the board. Not too many mistakes and only one of them required some real re-work. No green wire the first time out! I've assembled two of these now, one with 8 RG LEDs and one with 16. I'll wait for the next version to do a full 32-LED board.

Next stop, the CAN commuications controller.