- Read and write are a bit different. The address component of a read/write instruction is shifted over one. sort of.
- AVR parts can be programmed using the hardware serial support. usbasp can communicate with this or it has a software implementation. The 89S52 I tried it with didn’t seem to like the hardware way, but software works well.
Using usbasp and avrdude to program 89s52
I’m working on a project that requires the use of an 89s52. Well, it requires a 8051 footprint compatible part but I want In-System-Programability (ISP). So I need to be able to program the 89s52.
The cheap options for programming 89s52 parts are not that well documented on the web. More important, I already have a usbasp. Google’ing hints that it should be possible to program these guys with a usbasp, but there is lots of conflicting information.
Well, it is possible, but it requires some adjustments to the usbasp firmware and some additions to avrdude’s conf. The setup I’m describing is this post is one I’ve used to successfully program an 89s52 and an ATMega328p. Hopefully, no existing functionality is lost.
The firmware here www.mmccoo.com/electronics/usbasp.2012-07-20_89s52.tgz has my changes.
I also have it here untar’ed: www.mmccoo.com/electronics/usbasp.2012-07-20_89s52
This is my avrdude.conf file: www.mmccoo.com/electronics/avrdude.conf
What did I do?
I started with the information here: www.8051projects.info/content/8051-tools/14-usb-8051-avr-programmer.html. In particular, it contains a link to a version of usbasp firmare that should work, but I wasn’t able to get it to work. I can’t really say I tried super hard. The issue I had was the it seemed incompatible with recent avrdude versions. Given my new familiarity with the firmware quoted, it should work.
Anyway, the modified firmware was done on top of the original 2005 firmware. I took that diff and applied it to the most recent 2011 version. This process was pretty educational. There are a bunch of statements out there that are misleading, so I’ll try to dispell some of the. To be clear, I take no credit for any of the changes. I just merged to latest and tweaked a wee bit. The main point is that the version posted here works for me using avrdude 5.10 and a cheap ebay usbasp on 89s52 and ATMega328p. This the command I used:
avrdude -c usbasp -p 8052 -b 200 -U flash:w:blink.hex:i
It’s just the reset signal. One common statement that’s made is about how the 89s52 (and all other 8051 parts) reset signal is active high whereas most modern microcontrollers are active low. While this is true, it’s not enough to invert reset. There are several other ways that the usbasp assumes it’s dealing with normal AVR parts that also have to be addressed.
Is anyone out there? The most important trick that these modifications add is a stronger dependency on calling out to the part: “are you an AVR part?” Silence. Ok are you an 89s part? These calls are referred to as “Program Enable” in the datasheets and they are done differently between the two familes. In particular, AVR parts respond on the third byte. 89S parts respond on the 4th. Also, the responses are different. Again, the usbasp knows what it’s calling out to and it’s expecting a certain response. No amount of inverting changes that. It’s a neat trick though. Flash reset, try AVR call/response. Try flashing reset again (this time active high) and try 89S. I could imagine extending this trick further for other products that support serial programming
Change programming assumptions. Once this call/response process matches a product family, the usbasp will know what it’s dealing with and apply the proper assumptions; ones that are appropriate to that part. All of that can be taken into account.