An open letter to Senator Casey (and other SOPA/PIPA supporters)

Posted on 2012-01-18 by M. Eric Carr

The Honorable Robert P. Casey, Jr.
393 Russell Senate Office Building
Washington, D.C. 20510

Dear Senator Casey:

Although I have generally been not only a constituent but a supporter of yours, it was with some concern that I read about your support of the so-called “Protect IP Act“, or “PIPA” (S. 968) legislation, currently being reviewed in committee. While efforts to reduce IP content piracy can indeed be useful, S. 968 (as well as its counterpart in the House, H.R. 3261: “SOPA“), are dangerously broad in scope — and furthermore, would not even be effective at their stated goals of reducing online piracy.

Specifically, sir, such bills will restrict the activities of legal, productive websites far more than they will restrict the activities of online pirates. Although I am not an expert on the mechanics of BitTorrent, TOR, and similar technologies, even I can think of a half-dozen effective methods to counteract DNS filtering and so-called “deep packet inspection.” This technology will not do what it is claimed — pirates have been circumventing filters like this for years — but such restrictions will have very harmful side effects on legal, useful sites such as Wikipedia and YouTube.

Such invasive activities as S.968 proposes will, as many Internet advocates have noted, have a “chilling effect” on the majority of legal, online content. When even politically neutral sites such as Wikipedia deem the issue important enough to warrant a 24-hour blackout of the English language edition of the site, it becomes apparent that this is an important issue with the potential to cause great harm to the fundamental freedoms the Internet affords.

Senator, the open Internet is a unique, precious resource — in exactly the way Gutenberg’s invention of the movable-type press was. The freedom of expression and unimpeded exchange of information that it provides are vital to not only freedom, but the intellectual economy of the modern world.

I strongly urge you to withdraw your support of this bill, and pledge to vote against it should it come up for consideration by the full Senate or any committee on which you serve.

Respectfully yours,
M. Eric Carr
Philadelphia, PA
eric@paleotechnologist.net

 

Posted in Current Events, Digital, Digital Citizenship | Leave a comment

Made by Monkeys

Posted on 2012-01-16 by M. Eric Carr

Sometimes, humor can be an effective way of making a point about bad design choices. Products which fail — often spectacularly — due to poor design can still lead to better engineering practices, if they inspire a discussion about what went wrong and how to fix it.

Design News’ “Made by Monkeys” column is a good read, and is often informative. It’s a good exercise in engineering ethics to read through the articles and conclude what made each particular design “Made by Monkeys.” Often, cost is the driving factor: a few cents saved by cutting corners here and there doesn’t keep the design from working immediately, but causes problems down the road.

Here are a few especially good articles that I’ve come across:

Enjoy — and remember, sometimes the monkeys have valuable lessons to teach!

 

Posted in Design | Leave a comment

FPGAs for microcontroller geeks

Posted on 2011-12-25 by M. Eric Carr

If you’re like me, you’ve heard a lot about FPGAs and how useful they can be in a design. Perhaps you’ve read a bit about them, learning what they are and a bit about how they work. If your background (like mine) is in microcontroller-based design, though, getting started in working with FPGAs is not necessarily intuitive. Here are some of my thoughts and experiences as I begin working with FPGA-centric design.

Although FPGAs can often be a viable alternative to a microcontroller or microprocessor in a given embedded project, they are radically different devices. Microcontrollers are CPUs with various built-in peripherals and onboard memory, whereas FPGAs are collections of various logic units that are configured to perform certain (often very complex) functions. Programming a microcontroller involves writing a program to tell it how to behave. Programming (really, configuring) an FPGA involves creating a configuration file (a “bitstream”) that sets up the configuration of the FPGA to do the intended tasks.

In short, you tell a microcontroller what to do; you tell an FPGA what to be.

The traditional “Hello, World!” project for embedded systems is typically a blinking LED. Even as simple a project as this illustrates the difference in approach when using an FPGA as opposed to a microcontroller. When writing a “blinker” program for a microcontroller, the code would generally look something like this (using PIC-like C code):

void main(){
   TRISB = 0xFE;
   while(1){
      PORTB = 0x01;
      delay_ms(500);
      PORTB = 0x00;
      delay_ms(500);
      }
   }

This code would blink an LED connected to PORTB.0 on and off at a rate of 1Hz. The microcontroller would follow each command in sequence and change the LED state appropriately.

Conversely, when implementing a blinking-LED project with an FPGA, the general approach is to implement a digital circuit (using virtual gates, flip-flops, registers, counters, multiplexers, etc) to perform the same function. One strategy is to decide how you would implement the circuit using discrete (74xx, for example) digital logic, and then implement this design in either schematic form or your HDL design language of choice. (VHDL and Verilog are the two dominant languages; the following example is in VHDL):

entity blinker is
   Port (clk : in STD_LOGIC;
   led : out STD_LOGIC);
   end blinker;

architecture Behavioral of blinker is
   signal count : std_logic_vector(23 downto 0);
   begin
   process (clk) is
      begin
      if rising_edge(clk) then
         count <= count + 1;
         end if;
      end process;
   led <= count(23);
   end Behavioral;

This code describes a 24-bit counter which increments on each rising edge of the input clock. The LED is tied to the 24th bit of the counter; this divides the clock by 224 (about 16.7 million). The end result is that the LED blinks once every 224 clock cycles. With a 16MHz input clock, the LED should blink at a rate of not quite once per second.

This is a very simple example, taking up less than 1% of the resources of even small FPGA devices like the Xilinx Spartan3 series. By combining “entity” descriptions like these, though, larger, more complex designs can be implemented. As with C-style programming for CPUs, modularity makes development of larger and more complex designs possible. A top-down approach can be taken, for example, describing the inputs and outputs of the system as a whole, then breaking the internal function down into subsystems, circuits, and finally gates (Boolean expressions, etc.)

Although working with FPGAs can be unintuitive for designers used to working with procedurally-oriented devices like MCUs, there are many benefits. FPGAs can be much faster at certain tasks, since the device configuration can be optimized for specific operations. Efficient pipelines can be set up, for instance, to keep streams of data flowing. Most significantly, FPGAs are inherently massively parallel: rather than relying on a single CPU core processing a sequence of instructions one after the other, FPGAs are essentially a “sea of [logic] gates” that can work together or independently. Extending the above example, for instance, several dozen LEDs could be configured to each blink at a different rate, by duplicating the blinker design at various places in the FPGA, and modifying the count for each.

The largest drawbacks to working with FPGAs I’ve found, so far, is that they tend to be more expensive (tens of dollars for an entry-level FPGA like the Spartan3, as opposed to under $5 for a typical 8-bit MCU; really big FPGAs can be stupendously expensive), and more importantly are trickier to implement into a typical DIY project, since they tend to be available in QFN and similar packaging instead of the more hobbyist-friendly DIP format. Fortunately, modern dev boards like Digilent’s BASYS2 and Gadget Factory’s Papilio make prototyping easier.

Here are a few books that I’ve found to be useful. I’m starting out with an emphasis on VHDL and Xilinx Spartan3 parts, so the books I’m using tend to have those biases:

FPGA Prototyping By VHDL Examples

 

This is the primary book I’ve been using while getting started in FPGA projects in general and VHDL in particular. It is a step-by-step explanation of the important concepts in writing VHDL code, with a particular emphasis on Spartan3 FPGAs. Since both of the dev boards I use (Gadget Factory’s Papilio and Digilent’s BASYS2) use Spartan3 chips, this book has pretty much been a one-stop shop, thus far. If I were creating an undergraduate-level course in FPGA-based design, I would use this as the textbook, with the other two as recommended supplemental texts.
HDL Chip Design

 

Part textbook and part “HDL cookbook” containing all kinds of HDL designs in both VHDL and Verilog. It doesn’t strike me as the best book for starting out, but looks very useful as both a reference and a good way to learn more advanced techniques. I picked up a copy on Jeri Ellsworth’s recommendation. It’s not cheap (and can be hard to find), but looks to be well worth the money.
A VHDL Primer

 

This is a good introduction and overview of the concepts and syntax of VHDL. It is a bit more theoretical than the other two books, but does a good job of covering the language, and can be used as a language textbook and/or a VHDL desk reference.

I am working on a few FPGA-based projects, which I will post here when complete. My eventual goal is to develop standalone FPGA-based devices.

Posted in C, Coding, Digital, EET205, FPGAs, VHDL | Tagged , , , , , | Leave a comment

C pointers explained

Posted on 2011-12-23 by M. Eric Carr

Pointers are a very powerful tool in C and similar programming languages. They are special variables that don’t directly contain a value; rather, they “point to” (contain the starting memory address of) the location of a value stored in memory. This “pointed-to” value can be any type — an integer, a floating-point value, a struct, or even another pointer. A pointer, in other words, doesn’t have the information you’re looking for — but it tells you where to go to get that information.

The use of pointers allows the construction of powerful data structures, including linked lists, queues and dequeues, and data trees. The basic idea behind pointers is easy enough, once you understand the concept; it’s usually the syntax that programmers find confusing.

Here is yet another attempt (pointer syntax has been confusing people for decades) to end the confusion and explain, simply and clearly, how to get C pointers to do what they do, including why the special characters (asterisk, ampersand etc) are needed. (I’ll assume you are already familiar with the basics of C programming, including declaring and assigning standard variables etc.)

First, a quick summary for those already familiar with the concept of pointers, but wanting a quick, concise explanation of C pointer syntax. Here is the simplest way of thinking of it that I have come up with:

  • &  means “The memory address of the variable named…”
  • *  means “The contents of the memory location pointed to by…”

For example, “int *x” means “The contents of the memory location pointed to by x is an integer.” Likewise, “mypointer = &y” means “set mypointer equal to the memory address of the variable named y.” Note how the above intuitive definitions for & and * can be just dropped, verbatim, into place. Remove these symbols, and remove the definitions from the explanation, and the examples work in a non-pointer context.

If you’re not already very familiar with both C programming as well as the idea of pointer variables, though, the above explanation won’t be of much help. In that case, a more complete explanation of what is going on is needed. Read on.

Let’s start with a simple example: declaring myval to be an integer equal to three:

int myval = 3;

This is straightforward enough: myval now refers to the value stored in a specific (as-yet-unnamed) memory location. The value stored here is currently equal to three (and is implemented as a signed integer value, probably of 32 bits.) When this variable was declared, the program requested the operating system to allocate space to assign a variable. We, as programmers, don’t (yet) know exactly where in memory this value is stored, however. For basic C programming, it doesn’t matter — but when working with pointers, we might need to know.

Now, suppose we want to know where in memory myval is stored. (For now, trust me that this is a useful thing to know.) We create a “pointer” variable, which doesn’t itself hold data, but which holds the number of a memory location (ostensibly containing our data or something else of interest.)

int *myval_pointer;

This line creates a new “pointer variable” called myval_pointer. (It doesn’t have to have “pointer” in the name — that’s just to help us remember what it is, for now. I could have called it mypointer, testpointer, or Fred, for all the compiler cares.) This new variable is set up to hold a memory location. The “int” part tells the compiler that when we use this pointer to look up the contents of a memory location, we intend for the raw data there (bytes) to be interpreted as a signed integer.

Right now, though, this new pointer doesn’t yet point to anywhere useful. Depending on how the compiler is implemented, it will either be equal to zero or will contain a random value. (Remember, always initialize your variables yourself!) Let’s put this new pointer variable to use, and have it point to the location in memory where myval is stored. (We don’t know where this is — but the compiler does!)

myval_pointer = &myval;

This statement sets the value of myval_pointer to the address of myval (some large number, perhaps in the billions on a system with an address space size in the multi-gigabyte range.) The = is the usual assignment operator, and the & symbol stands for “the memory address of.” So now, myval_pointer does indeed point to the address of myval. (Remember, this is because we assigned it this way — not because of how it’s named.)

Now, let’s see what this new way of accessing memory can do.

*myval_pointer = *myval_pointer + 1;

This statement increments the value in the memory location pointed to by myval_pointer by one. (The * symbol can be thought of as meaning “the contents of the memory location pointed to by”) Since this memory location is the one used by myval, what we’ve done is really just increment the value of myval directly in memory, without referring to it by name. If we were to print out the value of myval now, it would be 4. Compare the above line of code to the following:

myval_pointer = myval_pointer + 1;

You might think that this would increment the value of myval_pointer by one, making it point to a location one byte higher in memory. This actually isn’t the case, though — the compiler takes it upon itself to increment the value by four, since that’s the size of the int value that it was declared to point to. This statement doesn’t affect the value of myval in any way. What it does is to make myval_pointer point to the next memory address above where myval is located. (This can be very useful when going through an array of variables, for instance.)

Here is a quick example program showing some of the ways that pointer-variable syntax works. Try making your own modifications to see what happens. I recommend compiling it with gcc for Linux, in a regular user (I.E. non-root) account.

//Basic C pointer operation examples
//M. Eric Carr / Paleotechnologist.net

#include <stdio.h>

int main(){

//Declare a simple integer variable
 int myval = 3;

//Declare a pointer-to-an-integer
 int* myval_pointer;

//Assign the address of myval to myval_pointer
 myval_pointer = &myval;

//Show the initial values of the variables.
printf (“myval is %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);

//This increments the value and does not move the pointer.        *myval_pointer = *myval_pointer + 1;
printf (“myval is now %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);

//This moves the pointer up by four (32 bits; one int).
//The value in the original location does not change.
*myval_pointer++;
printf (“myval is now %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);               *myval_pointer–;   //Undo this change.

//This also moves the pointer up by four (32 bits).
*(myval_pointer)++;
printf (“myval is now %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);
*myval_pointer–;  //Undo this, too.

//This increments the pointed-to value.
//(It’s unintuitive that ++ would have higher priority
// than the pointer dereferencing operator *, but
// there you have it.)
(*myval_pointer)++;
printf (“myval is now %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);

//What happens when we increment the pointer by one?
myval_pointer = myval_pointer + 1;
printf (“myval is now %d.\n”,myval);
printf (“myval_pointer is %#llX.\n\n”,myval_pointer);
*myval_pointer–;  //Undo this, too.

return(0);
}

…So what are pointers good for? What can they do? That’s actually quite an in-depth topic, but one of the most useful features of pointers is that they can be used to create “linked lists” and related data structures (trees, queues, and many more).

Unlike an array, which has to be allocated as a block of memory before it is used, elements can be efficiently added to, removed from, and moved around within a linked list. Instead of the “box of pigeonholes” metaphor of arrays, linked lists can be thought of as links in a chain. More links can be added, links can be removed from either end or anywhere in the middle, etc. With more advanced data structures, more complex structures can be created.

The way a simple linked list works is by setting up a custom data type. Whereas a simple data type would either contain a numerical value, a character, or perhaps a memory location (if it’s a pointer), this custom type would contain one or more pieces of data (the “payload,” and a pointer to the same custom data type.

This sounds unintuitive, until you realize that the addition of the pointer allows each data element to point to the next one in the chain. By maintaining a single pointer which points to the start of the list, a program can traverse the list, looking for a desired record, adding up totals, or whatever other operations are useful.

By convention, the pointer of the final element in the list is set to the value NULL, meaning that it doesn’t point to any memory location. If well written, code that examines the linked list by traversing it from start to finish is designed to check for this special NULL value, and stop processing when it reaches that point.


Posted in C, Coding, HOW-TO | Tagged , , , , , , , , | 4 Comments