Archive for May, 2012

The good old days were exactly that: Good.  These days, there is a vast number of problems to deal with that our predesscors did not even dream of worrying about. I’m not talking about all that climate change stuff, but the technology issues: Which phone to buy next, should I follow such-and-such on Facebook and (the one I am about to tackle) Arduino bootloaders defaulting to 57600 baud.

Whilst running at 57600 baud makes perfect sense when you are operating with a crystal oscillator, not all applications necessarily require this.  Sometimes, less is indeed more. The inaccuracy in the on board oscillator makes it difficult to operate at the higher baud rates.

There are a number of tutorials on the ‘tubes about configuring the ATMega328P chip (the Arduino chip)  to work with the internal 8MHz oscillator.   I’m not really trying to be user friendly with this post like most of the other authors aimed.  This is more of a “this is what worked for me” information dump, that may make this process faster for some other person.  The main changes that are required are:

  1. Change the Bootloader
  2. Change the Make File
  3. Recompile the Bootloader
  4. Program the Bootloader
  5. Modify the Arduino boards.txt to reflect this new configuration.

First and foremost – don’t do this unless you already know how to do this.  You could break stuff. I am not responsible for that stuff or anything else you may break by following this incorrect not-instructions. You have been warned.

Change the Bootloader

I am using the hardware\arduino\bootloaders\atmega\ATmegaBOOT_168.c as the basis for these modifications. Your experience and choice may vary, but this works for me!

The main change that needs to occur here is fixing the EEWE problem that can stop you building the software.  See here for the bug and here for a great writeup on this process.

If you have a custom board with a custom blinky LED location – you can also change where the bootloader blinks in this file.  Check around Line 131.

Other then that – follow the links and you should be good.  The baud rate here does NOT need changing (Line 97)

Change the Make File

Copy and paste from a known good working one – I chose the atmega328_pro8 configuration.  Change the baud rate setting to something slow, I am using 9600 which seems reliable. Done. Easy eh?

It should look something like this:

Recompile the Bootloader

I am not going to repeat this here, check that above mentioned link to here.

The gist is – make sure that all works with a known make configuration.

To compile the above modification is:

Following this, you should have the relevant hex file appear.

Program the Bootloader

Pick your favourite programmer, grab the above generated hex file and program away! If you have a blinky LED, it should be blinky after programming.

Modify the Arduino boards.txt to reflect this new configuration.

Again, copy the pro8 (or whatever you used as the starting point) configuration from hardware\arduino\boards.txt and paste into your user directory boards.txt.

Rename the configuration and then tweak the baud rate to the same number used in the make file and restart the Arduino software.  This new configuration should now appear.  The relevant lines that I added to my boards.txt file are:

Fuse Settings

A final note on fuse settings. The ones I am using with the above configuration are:
Extended: 0xFD
High: 0xD8
Low: 0xE2

Anyway, hopefully this makes the process a bit faster for somebody else!

So, I have finally gotten around to writing something again!

I have recently been working on a board that is using an FTDI FT2232H as the interface between an FPGA and USB interface. The requirement is simple, get data from FPGA to USB as fast as possible.

I have encountered some problems getting the FTDI chip to work properly in this mode.  Whilst the datasheet is reasonably good, and the application note on exactly this mode is concise (but logically correct) I kept on running into problems with the TXE# pin not going low, to permit data to be written to the internal FIFO.  All my software tweaks yielded nothing – the head banging was strong!  I put pen to paper and started writing my support email to the people at FTDI, working my way through the data sheet to explain what I had done.  All of the control lines were pulled in the correct directions. And then I found it, that crucial text: “Tie this pin to VCCIO if not used.

It turns out that that instruction is important when applied to the SIWU pin. Take heed.  As soon as the HDL code was modified to pull this line up – presto! It works!

Some of the undertakings demonstrated on this website are dangerous and should not be attempted by unskilled persons.
I take no responsibility for any damage done to persons, property or relationships as a result of this information.
Information is provided on the understanding that it is correct, but without any such warranty.
Any undertakings based on the contents of this site are done so at your own risk.