Show Posts
Pages: [1] 2 3
1  Development / Other Hardware Development / Re: Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 25, 2013, 10:10:15 pm
Quote
DIP-30 is a standard package, right?
IIRC 28 and 32 but not 30.

Yeah, that sounds right now that I think about it.  In that case I may stick with DIP-28, at the cost of those 2 I/O pins.
2  Development / Other Hardware Development / Re: Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 25, 2013, 12:22:15 pm
Rx0 and Tx0 are going out to a separate FTDI header on the end of the board (like the Pro Mini), That way the FTDI UART and D0/D1 pins are separate signals.  The JTAG pins go to a similar header, on the other end of the board.  Those two headers will stick "up" from the board so as not to interfere with the two main rows of pins that are meant to insert into a breadboard or ZIF socket.  If you look at my first post, you can see the two headers on the ends in the board pic.  I've just shrunk it to be 2 pins shorter in length (removing Rx0/Tx0 from the main pin rows and connecting a secondary oscillator to TOSC1/2).  RxLED/TxLED are currently not brought out to any external pins.  I may end up connecting them to an external pad, since now that I've shrunk it to DIP-28, I could always backtrack to DIP-30 and add those extra 2 pins back (DIP-30 is a standard package, right?), then I'd have all of the I/O pins broken out except C6/7, which are connected to the 32kHz crystal.

Edit: Just realized you were asking about software mapping of pins.  On the Goldilocks (which is what I'm basing my pinout off of), the I2C and JTAG pins don't seem to be assigned D#'s, they're just assigned signal names.  I may be wrong, I'll have to look a bit more into the board definition files...
3  Development / Other Hardware Development / Re: Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 25, 2013, 01:59:45 am
After a bit more looking into it, I decided to go with the Goldilocks pinout instead of what I had previously, so I should be able to mostly just use that board definition.  I made one change so that D[0..4] is RXD1, TXD1, SCL, SDA, instead of RXD0, TXD0, RXD1, TXD1 like the Goldilocks has it.  For the Rx/Tx LED's, I lose the external timer/counter inputs, the divided system clock output, and the USART0 clock input, but I can live with that, and I cut it down to a DIP-28 footprint, so that's nice.  The one unfortunate thing is that there's no way to fit the chip inside a 0.6" wide footprint with room for silkscreen without switching to QFN, and I don't want to do that, but I'll live with missing silkscreen on the middle few pins, and I'll just copy all of the pin names to the bottom silkscreen as well, so at least they're marked *somewhere* on the board.
4  Development / Other Hardware Development / Re: Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 16, 2013, 05:31:15 am
Really? Where were you looking?
Hmm... guess I didn't look closely enough last time I checked the full-size Arduino schematics.  The Pro Mini and Micro don't have it.
http://arduino.cc/en/uploads/Main/Arduino-Pro-Mini-schematic.pdf
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/Pro-Micro-v11-5V_B.pdf

Quote
I say "waste" because PWM pins always seem to be at a premium. If you're after SRAM instead and specific size, I can appreciate that too.
I may rethink the PWM pins.  I'll have to consider my options.
5  Development / Other Hardware Development / Re: Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 15, 2013, 04:48:13 pm
What "board type" will you be using for pinouts? Or will you be making up your own?

I'll be making my own board definition.

I see a lot of unrouted traces.

Yeah, I traced myself into a corner a bit, but typically when I do that, I need to step away for a bit and come back to it so I can see where things can be moved.  I figured in the mean time I'd seek feedback on the schematic end of things in case I'd done anything really stupid and needed to change something major.  No point going to the trouble of moving the traces around if I was just going to have to go back and rip them all up again...

You have 2 pins you are not bringing out at all? That is a waste. Especially as they are PWM pins.

You have 2 pins just driving onboard LEDs? That is a waste. That's 4 IO that you've taken away.

"Waste" is relative.  4 I/O pins out of the 32 available is not a huge deal.  I'm more interested in the large Flash and SRAM on this chip.  I made the intentional design choice of sticking to a standard 0.6" DIP-32 footprint so I can use this in a breadboard or standard socket, and I didn't want to go up to the next standard DIP size (DIP-40).  I could, of course, add the extra pins in the middle of the board like the A4/A5 pins on the Pro Mini, or the PORTA pins on the Teensy++ 2.0, but personally, I don't like doing that, and I know if I did, I'd never populate those headers.  If I really want all of the I/O's I'll go with a Goldilocks or a Bobduino or something else in a larger form factor.

Add a diode from RST/ (anode) to +5 (cathode) to prevent any spikes from looking like the start of a high voltage programming cycle, with results in the chip looking like it's hung.

I haven't seen this done in any of the AVR board reference schematics I've looked at, Arduino or otherwise, but for the cost of a diode it couldn't hurt.
6  Development / Other Hardware Development / Looking for feedback: designing a Pro Mini form-factor board with the Mega1284P on: November 15, 2013, 02:35:59 am
I've done a couple of design revisions of an Arduino-compatible ATmega1284P board, the first one designed to fit in the "normal" (Uno/Leonardo/etc) form-factor (like the "Goldilocks" board), but today I was playing around with making one in the Pro Mini's form factor.  I used the Pro Mini and SparkFun's Pro Micro as my references for pin assignment (other than the Pro Micro's maddeningly poor pin 3 assignment to GND instead of RST like it's supposed to be, which led to untold hours of debugging with the Mini USB Host Shield... but I digress...).  Anyway, I tried to match up pins to the Pro Mini by their auxiliary functions as much as possible, but I ended up having to make a few changes.

  • The FTDI Basic header is connected to RXD0/TXD0, but the pins on the breadboard header (D0/D1) are connected to RXD1/TXD1, that way I can use both UARTs
  • The ATmega328P has SDA and SCL on analog pins, so the Pro Mini assigns them as A4 and A5, the ATmega1284P does not have them on analog pins, so I'm using D2 and D3 like on the Pro Micro
  • Rx/Tx LED's moved to C6 and C7, since I wasn't using those for anything
  • I've extended the board length to accommodate the additional I/O pins of the ATmega1284P... so kind of a "Mini-Mega" form-factor
  • I added JTAG and ISP headers, in addition to the FTDI Basic header.

Anyway, I just wanted to run my schematic by a few people and see whether or not I'd made any silly mistakes, or if there was anything in particular I could improve with the design, especially wrt the pin assignment I've chosen.  I've attached my current schematic and my not-quite-completely traced PCB (I've kind of traced myself into a corner on the right-hand side, but I have a few ideas of what I can move around and to where, but I'll wait until I get some feedback on the schematic before I do any more work on the board).  Any comments or criticisms are greatly appreciated.
7  Development / Other Software Development / Adding a custom board to the IDE on: September 10, 2013, 09:58:38 pm
Has anybody created a guide for adding a custom board to the Arduino IDE?  I understand a lot of what is involved from looking through the packages provided for boards like the SparkFun Pro Micro, so I'm not looking for hand-holding here, the actual code I understand well enough, I just don't know quite all of what is involved in getting the IDE to properly recognize the new board definition, so I'm looking for more of a checklist of the required components.  From what I can gather, the required files are:

[ArduinoDir]\hardware\[PackageName]\boards.txt
[ArduinoDir]\hardware\[PackageName]\cores\arduino\*** (Arduino core files, modified for the specific board)
[ArduinoDir]\hardware\[PackageName]\variants\[VariantName]\pins_arduino.h

Also, the boards.txt file seems to be pretty powerful, the Teensyduino package takes advantage of this to do things like adding custom sub-menus to the Tools menu, and using the external Teensy uploader application.  Is there a good, in-depth guide to the more advanced features of boards.txt?  All of the guides I've seen have just glossed over the basics.  I'll be using one of the USB Atmegas, is there any way to get the Arduino IDE to program them via DFU?  Does AVRDude support DFU?  Otherwise, I'll have to figure out how to get the Arduino IDE to program via the FLIP command-line app (batchisp.exe, IIRC...), in a similar fashion to how Teensyduino programs via the Teensy loader.
8  Development / Other Software Development / Re: Decoupling shield libraries from the Arduino core on: February 26, 2013, 02:09:42 pm
Well, just to resolve this for anybody who might attempt this in the future, I was able to just include several of the Arduino core files in my project in order to satisfy the dependencies on them, but the one dependency I had to remove was the HardwareSerial library, because that relied on the CDC code (at least for the Atmega32U4 that I'm working with), which in turn depended on the entire USB core, which was what I was trying to get away from in the first place.  So the CLEAN solution would have been to re-implement the HardwareSerial interface (or at least the Serial_ class) using LUFA-compatible code, but 1)I didn't want a CDC interface in my device (though I suppose I could have implemented it via the UART instead of USB) and 2)I was lazy.  So I ended up just commenting out all of the Serial.println()'s in the shield library... which removed all of the serial debugging, but oh well.  Eventually, I'll probably just add a UART-based implementation of the Serial_ class and be done with it, but for now, it seems to be working...
9  Development / Other Software Development / Decoupling shield libraries from the Arduino core on: February 12, 2013, 03:57:27 pm
I've been really interested in many of the LUFA hacks that have led to custom devices on the Arduino by re-flashing the Atmega16U2 on the Uno and Mega2560 boards.  I'm in the process of building a project with USB MIDI output, and it works great on the Uno and Mega2560, using LUFA-based MIDI firmware on the 16U2, but I would really like to cut out the middle-man and target my project to the Leonardo, so the entire code base is running on a single microcontroller.  The problem is, I'm using the Circuits@Home USB host shield, and their libraries are coupled to the Arduino core, whereas I would rather utilize the LUFA build system, which allows me complete control of the USB device descriptors, allowing me to create any kind of device I want (which is why LUFA has been the go-to library for those sorts of hacks).  So my question is, has anybody here had any experience decoupling shield libraries from the Arduino core?  Or maybe the answer is to go a different route, and link the two code libraries... but I have a feeling that wouldn't work, due to my requirement for being able to control the device descriptors via the LUFA build system, where I'm pretty sure the Arduino core handles that itself.  I would really like to end up with a truly plug-and-play device, acting as a pure generic USB MIDI controller.  So there is my dilemma.  On the one hand, I have the LUFA code doing what I want it to do as far as the PC interface side of things, but on the other hand, I need the USB Host Shield library in order to communicate with the external devices I'm using to actually control the MIDI device.  Any suggestions?
10  Using Arduino / Networking, Protocols, and Devices / Re: Leonardo HID Gamepad on: November 08, 2012, 02:41:06 am
Nevermind, I missed the singleton instantiations at the top of HID.cpp.  IT WORKS smiley-grin smiley-grin smiley-grin

If anyone's interested (as I haven't found anyone else that's implemented the HID gamepad profile on the Arduino yet... I looked for one before trying to do it myself), I have a write-up on my blog: http://blog.qwertymodo.com/2012/07/arduino-hid-gamepad-part-1.html
11  Using Arduino / Networking, Protocols, and Devices / Leonardo HID Gamepad on: November 08, 2012, 01:33:38 am
I'm trying to implement an HID gamepad on the Leonardo.  I've already added the following to the device descriptor in HID.cpp (4 buttons, 2 axes):

Code:
    // Gamepad
    0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
    0x09, 0x05,                    // USAGE (Game Pad)
    0xa1, 0x01,                    // COLLECTION (Application)
    0xa1, 0x00,                    //   COLLECTION (Physical)
    0x85, 0x03,                    //     REPORT_ID (3)
    0x05, 0x09,                    //     USAGE_PAGE (Button)
    0x19, 0x01,                    //     USAGE_MINIMUM (Button 1)
    0x29, 0x08,                    //     USAGE_MAXIMUM (Button 8)
    0x15, 0x00,                    //     LOGICAL_MINIMUM (0)
    0x25, 0x01,                    //     LOGICAL_MAXIMUM (1)
    0x95, 0x04,                    //     REPORT_COUNT (4)
    0x75, 0x01,                    //     REPORT_SIZE (1)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0x05, 0x01,                    //     USAGE_PAGE (Generic Desktop)
    0x09, 0x30,                    //     USAGE (X)
    0x09, 0x31,                    //     USAGE (Y)
    0x15, 0xff,                    //     LOGICAL_MINIMUM (-1)
    0x25, 0x01,                    //     LOGICAL_MAXIMUM (1)
    0x95, 0x02,                    //     REPORT_COUNT (2)
    0x75, 0x02,                    //     REPORT_SIZE (2)
    0x81, 0x02,                    //     INPUT (Data,Var,Abs)
    0xc0,                          //   END_COLLECTION
    0xc0                           // END_COLLECTION

I've also added the following class declaration to USBAPI.h:

Code:
class Gamepad_
{
private:
uint8_t _buttons;
public:
Gamepad_(void);
void begin(void);
void end(void);
void press(uint8_t b);
void release(uint8_t b);
bool isPressed(uint8_t b);
};
extern Gamepad_ Gamepad;

However, when I try to call any of the Gamepad functions (Gamepad.begin(), Gamepad.press(), etc.), it throws an undefined reference to Gamepad.  So apparently, I'm missing something.  Can anybody with knowledge of the Arduino HID implementation help point me in the right direction?  If I comment out any calls to the Gamepad class, I can compile it and upload the sketch, and it shows up as a gamepad in Windows with 2 axes and 4 buttons, so the device descriptor is good.  I'm just missing a reference to my newly defined class.  Any ideas?
12  Using Arduino / Networking, Protocols, and Devices / First time with the Ethernet shield on: May 20, 2012, 08:14:27 pm
I'm currently trying to use my Arduino with an Ethernet shield to act as a simulator for a networked device in my university Junior Project.  We're currently running the simulation on a laptop, but just for kicks, I wanted to try to make it work on the Arduino.  Basically, we're writing an iPad app capable of communicating with a vehicle over a network for diagnostics and such, and the Arduino is going to simulate the vehicle side of things.  Basically it's running as a server, receiving commands from the iPad, and shipping out data packets at regular intervals describing the current state of the vehicle (gas/battery levels, rpm, speed, etc.).  Currently, I have the iPad able to establish a connection with the Arduino and recognize that it receives at least the initial data packet (I have not yet added the code for simulating changes in the data like gas/battery levels decreasing over time, change in speed, etc.), but at some point, it just freezes up.  I didn't write the iPad code (other members of my team were responsible for that), but here is my current Arduino code.  It's my first time doing networking with the Arduino, so I'm sure I just messed up something simple.  Also, the use of a statically allocated struct and memcpy for my payload is a hack, I know, but the I couldn't find any decent method of serializing the data, and the String class is useless, so it's the least of the evils I could devise, and according to Wireshark, it's working, so that's good enough for me.  I have a momentary pushbutton between pin 52 and GND, and for now it's just toggling a single value so I can see if it's working or not (it isn't.  pushing the button freezes the Arduino until I release it, and if I hold it too long it never resumes).  Any help is greatly appreciated.

Code:
#include <SPI.h>
#include <Ethernet.h>
#include <EthernetUdp.h>
#include <TimerOne.h>

#define CLOCK 1000000

// Define MAC address and destination port
byte mac[] = {  0x90, 0xA2, 0xDA, 0x00, 0x92, 0xFB };
IPAddress broadcastIP;
unsigned int localPort = 55555;

float fuel_level = 1.0;
float battery_level = 1.0;
int speed = 0;
int electric_rpm = 0;
int ic_rpm = 0;
bool electric_on = 0;
bool ic_on = 0;
int battery_temp = 0;

/*
<?xml version="1.0" encoding="UTF-8"?>
<data>
    <fl>[info]</fl>
    <bl>[info]</bl>
    <sp>[info]</sp>
    <emr>[info]</emr>
    <icr>[info]</icr>
    <ti>[info]</ti>
    <emto>[info]</emto>
    <icto>[info]</icto>
    <bt>[info]</bt>
    <bs>[info]</bs>
    <ss>[info]</ss>
</data>*/
struct {
  char t1[50];
  char fl[8];
  char t2[10];
  char bl[8];
  char t3[10];
  char sp[8];
  char t4[11];
  char emr[8];
  char t5[12];
  char icr[8];
  char t6[23];
  char emto[1];
  char t7[14];
  char icto[1];
  char t8[12];
  char bt[8];
  char t9[26];
} udpPayload;

char buffer[10];

EthernetUDP Udp;
EthernetServer server = EthernetServer(localPort);
EthernetClient client;

boolean connected = false;

void setup() {
  pinMode(13, OUTPUT);
  pinMode(52, INPUT);
  pinMode(53, OUTPUT);
  digitalWrite(52, HIGH);
 
  Ethernet.begin(mac);
  server.begin();
  Udp.begin(localPort);
  Serial.begin(9600);
  delay(1000);
 
  // give the Ethernet shield a second to initialize:
  Serial.println("connecting...");
  Serial.print("Local IP Address: ");
  Serial.println(Ethernet.localIP());
 
  broadcastIP = Ethernet.localIP();
  broadcastIP[3] = 255;
 
  memcpy(udpPayload.t1, "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<data>\n<fl>", 50);
  memcpy(udpPayload.t2, "</fl>\n<bl>", 10);
  memcpy(udpPayload.t3, "</bl>\n<sp>", 10);
  memcpy(udpPayload.t4, "</sp>\n<emr>", 11);
  memcpy(udpPayload.t5, "</emr>\n<icr>", 12);
  memcpy(udpPayload.t6, "</icr>\n<ti></ti>\n<emto>", 23);
  memcpy(udpPayload.t7, "</emto>\n<icto>", 14);
  memcpy(udpPayload.t8, "</icto>\n<bt>", 12);
  strcpy(udpPayload.t9, "</bt>\n<bs></bs>\n<ss></ss>");
 
  Timer1.initialize(CLOCK); // Set up a timer at the defined resolution
  Timer1.attachInterrupt(tick); // Attach the tick function
}

void loop() {
  // if an incoming client connects, there will be bytes available to read:
  client = server.available();
  if (client) {
    if(!connected)
    {
      client.flush();
      Serial.println("Connected to client.");
      connected = true;
    }
    // read bytes from the incoming client and write them back
    // to any clients connected to the server:
    while(client.available()) {
      char buf = client.read();
      Serial.print(buf);
    }
    //Serial.println("");
    client.stop();
   
    battery_temp = digitalRead(52);
  }
}

void tick() {
  updatePayload();
  broadcastPayload();
}

void updatePayload() {
  dtostrf(fuel_level, 3, 6, buffer);
  memcpy(udpPayload.fl, buffer, 8);
  dtostrf(battery_level, 3, 6, buffer);
  memcpy(udpPayload.bl, buffer, 8);
  sprintf(buffer, "%8d", speed);
  memcpy(udpPayload.sp, buffer, 8);
  sprintf(buffer, "%8d", electric_rpm);
  memcpy(udpPayload.emr, buffer, 8);
  sprintf(buffer, "%8d", ic_rpm);
  memcpy(udpPayload.icr, buffer, 8);
  sprintf(buffer, "%1d", electric_on);
  memcpy(udpPayload.emto, buffer, 8);
  sprintf(buffer, "%1d", ic_on);
  memcpy(udpPayload.icto, buffer, 8);
  sprintf(buffer, "%8d", battery_temp);
  memcpy(udpPayload.bt, buffer, 8);
}

void broadcastPayload() {
  Udp.beginPacket(broadcastIP, localPort);
  Udp.write((uint8_t *)&udpPayload, sizeof(udpPayload));
  Udp.endPacket();
}

13  Using Arduino / Networking, Protocols, and Devices / Trying to convert project to use alternative USB<->RS232 UART chip on: March 21, 2012, 06:57:35 pm
I'm in the process of building a project that I found online that uses an Atmega 8515 and an FTDI FT232BL USB<->RS232 UART converter.  I'm wondering if it is possible to replace the FT232BL with the Texas Instruments TUSB3410 as a straight drop-in replacement, or what considerations will have to be made in switching the design from the one chip to the other.  The reason I want to do this is simply because I have several of the TI chips laying around and I'd like to use what I have if at all possible.  I understand that this is a question that is highly dependent on which functions of the chip I intend to utilize, as I can see that the chips do differ in features.  However, it seems that the project I'm working with really just uses the bare minimum USB<->RS232 functionality on the chip, so I'm hoping that it can be done.  The difficult part is that I don't have access to the code used to program the Atmega, so I'd need for the TUSB3410 to interface identically (but this shouldn't be an issue because USB and RS232 are both standardized protocols, so as long as I hook up to the right pins the operation should be identical, right?  Or is it more complicated than that?).  I realize this might not be a simple question to answer entirely, but any help at all pointing me in the right direction (or else a straight "not gonna happen") would be greatly appreciated.

For reference, here's the schematic for the project I'm building:
http://www.reinerziegler.de/GB-Flasher/schem+pcb/GB%20Cart%20Flasher%20(USB).pdf

And here are the datasheets for the two chips:
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232BL_BQ.pdf
http://www.ti.com/lit/gpn/tusb3410
14  Using Arduino / Microcontrollers / Re: ArduinoISP programming Atmega8515 on breadboard on: March 14, 2012, 12:01:09 am
I finally got it working using the ArduinoISP example sketch modified to run at 9600.  The TinyISP sketch you emailed me did not work.  Thanks for the help in getting this all working smiley
15  Using Arduino / Microcontrollers / Re: ArduinoISP programming Atmega8515 on breadboard on: March 13, 2012, 11:42:09 pm

Try the "arduino" protocol...

avrdude -p m8515 -P com7 -c  arduino  -v -v -v -b 19200 -U flash:w:gbcf-fw-2.1-usb.hex


Finally, some headway smiley  Unfortunately, new errors smiley-sad

Code:
C:\>avrdude -p m8515 -P com7 -c  arduino  -v -v -v -b 19200 -U flash:w:gbcf-fw-2.1-usb.hex

avrdude: Version 5.10, compiled on Jan 19 2010 at 10:45:23
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"


         Using Port                    : com7
         Using Programmer              : arduino
         Overriding Baud Rate          : 19200
         AVR Part                      : ATMEGA8515
         Chip Erase delay              : 9000 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom         4    10   128    0 no        512    0      0  9000  9000 0xff 0xff
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           flash         33     6    64    0 yes      8192   64    128  4500  4500 0xff 0xff
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           calibration    0     0     0    0 no          4    0      0     0 0 0x00 0x00
                                  Block Poll               Page      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0 0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.18
         Topcard         : Unknown
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATMEGA8515
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9306
avrdude: safemode read 1, lfuse value: e1
avrdude: safemode read 2, lfuse value: e1
avrdude: safemode read 3, lfuse value: e1
avrdude: safemode: lfuse reads as E1
avrdude: safemode read 1, hfuse value: d9
avrdude: safemode read 2, hfuse value: d9
avrdude: safemode read 3, hfuse value: d9
avrdude: safemode: hfuse reads as D9
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: please define PAGEL and BS2 signals in the configuration file for part ATMEGA8515
avrdude: reading input file "gbcf-fw-2.1-usb.hex"
avrdude: input file gbcf-fw-2.1-usb.hex auto detected as Intel Hex
avrdude: writing flash (3614 bytes):

Writing | ################################################## | 100% 5.67s

avrdude: 3614 bytes of flash written
avrdude: verifying flash memory against gbcf-fw-2.1-usb.hex:
avrdude: load data flash data from input file gbcf-fw-2.1-usb.hex:
avrdude: input file gbcf-fw-2.1-usb.hex auto detected as Intel Hex
avrdude: input file gbcf-fw-2.1-usb.hex contains 3614 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 3.02s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0010
         0x87 != 0x88
avrdude: verification error; content mismatch

avrdude: safemode read 1, lfuse value: e1
avrdude: safemode read 2, lfuse value: e1
avrdude: safemode read 3, lfuse value: e1
avrdude: safemode: lfuse reads as E1
avrdude: safemode read 1, hfuse value: d9
avrdude: safemode read 2, hfuse value: d9
avrdude: safemode read 3, hfuse value: d9
avrdude: safemode: hfuse reads as D9
avrdude: safemode: Fuses OK

avrdude done.  Thank you.
Pages: [1] 2 3