Wow. That's like a splash screen from the 90s or something!
While Steve refused to give up, I went down a slightly different route. Having recently discovered that the latest Oshonsoft AVR Simulator included support for both the ATMega128 and ATMega165, I threw together a simple blink test and compiled to a .hex file (which the compiler did a great job of creating, at a meagre 240 bytes in size!)
With the Oshonsoft compiler creating the hex file, we were both neck-and-neck: hex file built, just the programming to go. Steve spent a while messing about with the USBTiny config files, trying to add in support for the ATMega128 but the nearest he got to completion was an error message in the avr-gc executable - highlighting the character "h" at the beginning of an innocuous looking entry in the modified config file.
In the meantime, I was having problems of my own.
Despite always running my laptop in "disabled digital driver enforcement mode" there was something about the USBASP programmer that Windows 8.1 really doesn't like. I had to reboot the laptop twice; both times to disable digital signature signing, to enable the device to work. (there are plenty of links on the net about how to disable digital signing so there's no need to go into detail here - except to say that a lot of guides are out of date and that the location of different settings has changed under Windows 8.1 in the later updates; I spent ages only to discover that the settings I wanted were no longer under "general" but "restore pc")
Having finally got the usbasp device installed, it was time to stick some code onto the chip. Taking extra care to wire the programmer to the breakout board, I downloaded and installed a GUI front-end for the command-line programming tool avr-dude (called AVRDudess).
It's worth noting that for the ATMega128, the programming lines are on pins 2+3 (the PDI/PDO lines) and not the dedicated SPI MISO/MOSI lines as suggested by some sources. It's important to route the programmer to the PDI/PDO lines if you're building a programming header onto your project!
After selecting the programmer from the list, I hit "detect" and the software correctly identified the chip as an ATMega128. I hit "read" to get the current fuse settings from the device. Suddenly I was back in familiar territory - no longer was everything abstracted away and hidden behind cute menus in the Arduino IDE; this was programming the way I was used to - create a file, burn it to the chip. I could have been using Oshonsoft's PIC simulator/compiler and PICKit2, it felt so familiar!
Making sure the fuses are correctly set is a critical part of programming any device, whether an AVR chip or a PIC microcontroller. Luckily, there are a number of resources available online to generate the appropriate values for most AVR chips.
Programming the chip was super-fast; verifying the contents was really easy and after coding the chip, I changed the firmware and ran validate again (expecting, and getting, an error message to confirm that the programmer had actually put some data onto the chip). At first the board subbornly refused to run after being programmed. There was no real indication why....
...except on some forums, there was talk of the M103 flag.
A few people said to "look out" for it. A couple of people said "it always catches the newbies out" - but no-one actually said what it was, what it did, or how it affected programming (or running) the firmware on the chip.
By default the option was ticked. After checking and re-checking all the wiring, trying a different crystal to make sure it wasn't that, and burning different versions of the firmware to the chip, I tried unchecking the M103C option and burning the code again.
This time there was rapturous joy, as the little LED starting blinking away furiously (it was set to flash 10 times a second, after all!). So there we have it - we finally have a way of compiling code for and programming the ATMega128 chips, using a dedicated programmer (not the USBTiny and Arduino IDE combo).
What's great is that it allows us to write the code using the Oshonsoft compiler, just as we do for our PIC projects. The software simulator is really very good - so should we need to use AVR chips on any future projects, we'll be able to code the project up, simulate all the components (external devices like character LCDs, stepper motors, I2C eeprom etc can all be simulated, and all the register values can be read by pausing code execution during the simulation) and make an entire working project, before having to solder a single wire!
Getting the usbasp programmer to work was a bit of a pain, but far easier than the job Steve had, negotiating and updating config files and settings files and reinstalling different, older, crusty versions of the Arduino IDE. And being able to throw some code together in Oshonsoft is a bonus; at last we can write code for AVR chips without having to go near the Arduino IDE! (and even if it's necessary in future, we can always use avr-dude and usbasp to drop a compiled .hex file onto a chip, without having to mess about with config files and go through the - ultimately unsuccessful - hassle that Steve did, trying to get a different programmer to work, or a non-supported chip to work with the usbtiny!)
Now we've got a working programmer, and have successfully identified which pins are necessary to program the chip, it's time for yet another pcb layout. The good news is, it's BuildBrighton's Nerd Night tomorrow evening, so we'll have an opportunity to etch yet another board - only this time, actually stick an mcu on it and try it out for real!