Friday, September 3, 2010

Robot Logic, Part 1

UVOG has decided to make a robot as a club project. It will consist of Open Hardware and Open Software, and be easy for people to make at home on the cheap by repeating our steps.
My specialty is the software. So far, we have decided to use a handful of ATtiny2313 chips to control the various appendages and modules of the robot. The ATtiny2313's will be hooked up to a root controller of a type that is yet to be determined. So, I'm going to be learning AVR assembler to program the ATtiny2313 chip, but for now, I've been doing my experimenting with C. Assembler actually looks easier to use in this case, since I am so interested in direct pin manipulations and our memory space is so limited (2k program memory plus 256 bytes of SRAM and 256 bytes of EEPROM.)

One of my eventual goals is to learn the self-programming functions of the AVR instruction set so that I can reprogram any chip in the robot in place without any additional wiring other than that which we are using to send instructions from the root controller to the sub-controllers, but for now (until I have taught the chip how to do this), I have to use an external programmer.

Programming the Microcontroller

I've used three different programming boards for the 2313 so far. The first one was a hand-made parallel port programmer, which pulled its current from a USB connector. The second one is a board from Evil Mad Scientist which connects to the PC entirely with USB, through an adapter. Both of these were ok, except I kept having to pull the IC from the programming board, and put it on my breadboard for testing, then after failing (it is inevitable), pulling it again and returning it to the programming board. The third programmer is also a hand-made one, but this time it has two female headers running the length of the chip that I can plug test wires into. It also has a six-pin connector to attach or detach the parallel cable, which is a lot easier than running around behind the computer every time.

My debugging process now looks like this:

Plug the IC into the programming board. Plug the USB and Parallel into the PC, and plug the other end of the Parallel into the programming board. I will leave the IC , the USB and the Parallel (on the PC side) plugged in the entire time I'm working. The only cable I will unplug during the debug process is the programming board side of the parallel cable.

So far, I have not been using the UCSK, MISO, MOSI, or RESET pins (a.k.a., pins 1, 17, 18, or 19) in my actual experiment, so I can leave the IC on the test board, and hook up my other components by jumping a wire from the headers to the breadboard.

I unplug the single wire going from GND (pin 10) to the breadboard's ground bus, and I plug in the six-pin parallel connector, then run "make", and my toolchain compiles and automatically uploads the compiled code into the chip. Next, I plug the wire from pin the breadboard's ground bus back into pin 10 (GND) on the header, and I unplug the six pin connector, which releases the RESET pin causing the chip to boot up and run my code.

When I want to test again, I simply unplug GND and plug the six pins back in.

If I simply need to reset the chip to test the boot sequence again without reprogramming it, I can either apply a GND lead to the reset pin, or plug the 6-pin parallel connector in momentarily to accomplish the same thing.

How I Plan to Use the Chip

The 2313 has a nice amount of general purpose input/output pins. They have given names to the pins to indicate how they are treated internally as "ports." Along the "left side" of the chip, we have RESET (which doubles as PA2), then we have PD0, PD1, PA1, PA0, PD2, PD3, PD4, PD5, and GND. And going up the right side of the chip we have PD6, PB0 through 7, and VCC (our voltage source.)

For most of the chips in this project, I plan to use them in the following way:

Pin 1, 10, and 20 are keeping their purposes as RESET, GND, and VCC. Although repurposing RESET is possible, it is dangerous because it disables the programmability of the chip (RESET is normally held low while the chip is flashed.)

All the other pins down the left side are going to be used as inputs, in addition to pin 11 (the bottom pin on the right side.) This gives us a total of nine input pins which are known internally as PORTA and PORTD (with the exception of PORTA bit 2, which is reset.) When used as inputs, the values are actually read from the ports called PINA and PIND. All of the remaining pins on the right side will be used for outputs, which is known internally as PORTB.

Quick Review:
Input: 2 bits of PORTA and all 7 bits of PORTD. (actually PINA and PIND)
Output: All 8 bits of PORTB.

Some of our inputs have special functionality that we will be interested in, so we need to be careful to reserve those for the purposes we intend to use. Specifically, pin 6 and 7, a.k.a., PORTD2 and PORTD3 are the lines used to raise INT0 and INT1. INT0 is interesting to us, because it is the only regular user-definable interrupt that can raise the micro-controller out of its power-saver or sleep condition. (I don't remember exactly the term used for this particular sleep mode at the moment.)

I plan to use INT0 and INT1 to "talk to the chip" from the root controller.

This leaves us with the following general purpose inputs, which I would tend to utilize in the following manner:

Most Significant - - - - - Least Significant
PD6, PD5, PD4, PA1, PA0, PD1, PD0

If I care to get this into a single byte (sans the high bit), I think I can do so by performing the following bitwise operation:

MyInput = ((PIND & 0x73) | ((PINA & 0x03) <<>

Because the ATtiny2313 uses internal pull-up resistors, the default state of all the pins will read as high values (1). To toggle a pin, we must apply ground to it, which will lower it to zero. In other words, when we are dealing with inputs, "low means active." We might, therefore, want to inverse the value of all bits of input, so that we can logically use 1 to indicate active and 0 to indicate inactive.

Gotta run, I will post more on this later.

Thursday, August 19, 2010

Support for older Intel Graphics Chipsets in Lucid Lynx

For those having trouble getting Intel Brookdale G [82845G/GL] and similar chipsets to work on Ubuntu 10.04, I have good news. The Ubuntu Wiki has a page containing workarounds and fixes for the issue. My preferred choice right now is to install the backported Maverick kernel. This is also good news, because Ubuntu 10.10 should be expected to work on these machines without adjustment. Of course, if you just want the system to work with basic office-style functionality, VESA mode is a good alternative, but it will disable accelerated video.

Thursday, August 12, 2010

Tuesday, August 3, 2010

Tutorial on making colored maps

This Tutorial uses a Python script and free SVG maps to make maps based on csv data files! I know what I'm going to be doing tonight when I get off work!

How to make a US county thematic map using free tools [flowingdata.com]



Edit:
Michael made his own version of the same map following the tutorial! Here it is:



Video, State of Free Software

Listen to this video of Eben Moglen's presentation on the State of Free Software.

Monday, August 2, 2010

Oregon's E-Cycle program flawed

We are required by law to print the following three lines on receipts for purchases of new computers or monitors, or to distribute one of several graphical alternatives:

Oregon E-Cycles: Free Recycling
for Computers, Monitors and TVs
www.oregonecycles.org 1-888-5-ECYCLE

Unfortunately, the Oregon E-Cycles program is seriously flawed and could hurt the freedom of the economy and the freedom of choice of consumers. Don't get me wrong. I support and encourage recycling and care for the environment, but this law over-reaches its purpose. The e-cycle website states: "Only those brands listed as pending or compliant may be sold in or into Oregon. If a brand is not listed, it may not be sold. Sales restrictions apply to all types of sales including retail, catalog, phone and Internet sales."

The DEQ decides the fee that a particular manufacturer must pay to register. If they don't pay up, they aren't allowed to sell their product [legally] in Oregon. DEQ determines the fee based on statistical information which they acquire in order to determine the market share held by the brand in question. They start with national statistics and adjust it based on a limited amount of local statistics. The minimum fee right now is $40. If a brand has more than 0.01% market share based upon DEQ's manipulated statistics, the fee goes up to $200. For brands with more than 1%, the fee is $15,000, which is the amount they are apparently collecting from prominent national manufacturers such as Dell and HP-Compaq.

Imagine if every state implemented an identical program. Dell would have to pay three quarters of a million dollars every year just to be an authorized manufacturer, and that money does not go towards recycling. The manufacturers pay for the recycling fees themselves. A little shop that assembles generic computers would have to pay a combined $2000 to all fifty states, which might be more than they make in computer sales during the year, especially if new computer sales is not their main line of business.

This is, of course, a bad scenario. It is unlikely that all fifty states would demand payment from a vendor. The states would have to become aware of that brand being imported into their state before they would likely make such a demand, and even so, is it enforceable if another state demands that you pay them a fee just because someone carried your product across state lines?

Also, what's to say that a particular state can't raise the rates or file you in a higher market-share tier in order to pressure you out of the business. If I was a vendor in another state, and Oregon DEQ contacted me, I would be tempted to simply disable shipping to Oregon on my website, and place a warning label on my packaging saying that the product may not be imported into Oregon by the original owner--that's right! Used and refurbished equipment is exempt from the program.

Here's the bad part of the law: Oregon is shooting itself in the foot because it is trying to force manufacturers around the world to comply with its fees, which could reduce the choice that customers living in Oregon have on what they may purchase. Someone will have to set up a company just across the border that will purchase a new computer for you from a non-compliant manufacturer, then resell it to you as used equipment.

Frankly, I shouldn't have to pay fees to any other states, and other companies shouldn't have to pay fees to my state. No taxation without representation! If the states want to have purchasers pay fees because they purchased a computer or monitor, then the state should include this on the tax forms for their own residents.

Now, from the retailer point of view. Other than my purchasing options being limited by a list of brands put out by DEQ, which is quite disturbing, I also notice that I had the choice of using the three lines shown above on my receipts, or including one of the other printed materials of which there is a wide variety. The problem? All the materials are in color, and the section on logos specifically says that if you need alternate format logos including B&W that you must contact DEQ manually to request it. Why would a recycle program require me to print in color? They must want me to recycle my cyan and yellow toner cartridges on my laser printer more often. Well, I opted for the three lines instead to conserve toner, and to avoid showing the logo of this program which I detest.

Think about how much time and money is wasted handling all the extra paperwork, calculating annual market share reports, and certifying manufacturers. This process needs to stop.

If you too find this law to be over-reaching and limiting of your freedom, or believe that it does not serve the interests of recycling or caring for the environment, please contact your state senators and let them know that the flaws of this program need to be exposed so that action may begin to correct it and implement proper recycling legislation in its place.

Tuesday, July 27, 2010

Response to .DOC Attachment

What do you do when you receive an email file attachment in Microsoft's .DOC format? Sure, we could open it in OpenOffice.org and go about our business, but there's no guarantee that this will remain true for future versions of .DOC. Use of proprietary formats are a danger to interoperability and to future innovation. One good thing to do is to reply to the email and explain why they should send the attachment in a standard format. I've seen several canned email responses in the past, but most are too brief to explain the issue, or too harsh in their wording to satisfy my tastes. I was prompted to write a response after receiving such an email attachment today, and I have combined some of the best ideas from elsewhere and added some of my own. Here is what I would recommend:
The document you have sent was not saved in an accepted format for Internet mail.

It was saved in a proprietary format that is unreadable on several types of computers because the method for decoding the document is kept secret by Microsoft and is purposefully changed with each new release of Microsoft Word so that existing users of Microsoft Word will be forced to pay for expensive upgrades in order to continue to read Word Documents sent by others. For example, in 2010, Microsoft Office Home & Business 2010 was priced at $279.99, and Microsoft Office Professional 2010 was priced at $499.99.

Recent versions of Word have started using a newer, patented OOXML format. In many countries, it is actually illegal for other products to decipher this format. This is a lock-in technique used by Microsoft to maintain their monopoly on Office software, and by extension, their monopoly on the operating system market, since they have not released a cross-platform version of Microsoft Office compatible with other operating systems.

In most cases, the size of the file saved in Microsoft's secret, proprietary format is also substantially larger than a standards compliant file containing the same information and the same formatting.

It is also important to note that Microsoft Word documents are often infected with viruses. Excel, Access, and Power Point files are also vulnerable to infection. This potential for infection is largely due to the Macro language and the "Visual Basic for Applications" language which are built into the format to provide powerful programming capabilities. While powerful, these features were not protected with proper security precautions, and the majority of users do not actually use these features or even know that they exist.

What to do instead:

If you continue to use Microsoft Word, please have the courtesy to “Save As” one of the following formats: ODT (if available), DOS Text, HTML, or Portable Document Format (PDF) and after saving, send the resulting file as an attachment.

Alternatively, you could use a product such as AbiWord, KOffice, Google Docs, NeoOffice, or OpenOffice.org that allows you to save your document in the Open Document Text Format (ODT), which is an ISO/IEC International Standard, and is supported by such notable companies as Apple, Adobe, Google, IBM, Intel, Nokia, Novell, and Sun Microsystems. If you don't have one of these programs, I would recommend OpenOffice.org, which may be downloaded free of charge and used for any purpose, personal or commercial.

A third option is to simply type your message directly into mail (instead of typing into Microsoft Outlook or Microsoft Word) so that you won't need to use an attachment at all.

In the highly unlikely event that your document cannot be converted to an open, non-proprietary format, consider printing it and mailing it by post, or scanning it, and sending it in a standard graphic format such as PNG or JPG.

Thank you.