For the Microcontroller Comparison I have been trying to get the AT89LP6440 to work. When I sampled the chip I thought it could be programmed over serial with an FTDI cable like the DS89C450, but it turns out that it needs a parallel port. There are adapters and programmers that will simulate a parallel port over USB but I don't want to buy one for a chip that I might not use much in the future.
As a workaround I used the FTDI cable to bitbang the SPI interface. This was tricky because I had to write a whole new loading program instead of relying on the program Atmel supplies. Thankfully, they provide very good documentation of the ISP specification. Bits are sampled on MISO on the falling edge of the clock and MOSI is sampled on the rising edge. My first version of the program worked well but could only upload about 100 bytes of firmware per second. Part of this is due to reading MISO every clock cycle, which is not always necessary. By splitting reading and writing into different functions and sending pin states in groups instead of individually, flashing is much faster. There is a bug, though, that randomly gives a wrong byte when I try to read from the chip to verify the firmware. The wrong byte is always at a different address and sometimes the verification completes, so I know the AT89LP6440 has been programmed properly. I wasted about a week trying to tweak the program and saw that the D2XX drivers supplied by FTDI are unreliable and pretty buggy (at least when used under Windows 7 for bitbanging). This particular problem could be with the chip but several of the other D2XX functions I tried didn't work very well either. The same problem happens with both synchronous and asynchronous modes. There is an open source library called libFTDI but I didn't get very far with it because installing the driver for it would mean losing the virtual COM port you get with the FTDI driver. The next step would be to program the chip using another microcontroller connected to the PC over UART but I don't want to waste any more time on this chip since I am unlikely to use it for anything after the microcontroller comparison.
You can download the program here: AT89Loader. Flashing seems to work with no problems but verification occasionally fails.
As a workaround I used the FTDI cable to bitbang the SPI interface. This was tricky because I had to write a whole new loading program instead of relying on the program Atmel supplies. Thankfully, they provide very good documentation of the ISP specification. Bits are sampled on MISO on the falling edge of the clock and MOSI is sampled on the rising edge. My first version of the program worked well but could only upload about 100 bytes of firmware per second. Part of this is due to reading MISO every clock cycle, which is not always necessary. By splitting reading and writing into different functions and sending pin states in groups instead of individually, flashing is much faster. There is a bug, though, that randomly gives a wrong byte when I try to read from the chip to verify the firmware. The wrong byte is always at a different address and sometimes the verification completes, so I know the AT89LP6440 has been programmed properly. I wasted about a week trying to tweak the program and saw that the D2XX drivers supplied by FTDI are unreliable and pretty buggy (at least when used under Windows 7 for bitbanging). This particular problem could be with the chip but several of the other D2XX functions I tried didn't work very well either. The same problem happens with both synchronous and asynchronous modes. There is an open source library called libFTDI but I didn't get very far with it because installing the driver for it would mean losing the virtual COM port you get with the FTDI driver. The next step would be to program the chip using another microcontroller connected to the PC over UART but I don't want to waste any more time on this chip since I am unlikely to use it for anything after the microcontroller comparison.
You can download the program here: AT89Loader. Flashing seems to work with no problems but verification occasionally fails.
No comments:
Post a Comment