close-circle
Close
0%
0%

PIC89PROG

Atmel AT89C devices programmer built around PIC16, just for the lulz

Similar projects worth following
close
I have a few programmers here, so why not add another one? This is older project, but decided to place it here, to have all project at one place.

When I started one of my projects, I thought it could be nice to have it multiplatform. Similarly to my Rotary Dial Mobile Phone, which was tested with both ARM Cortex M0 and PIC16F1xxx platform, with only single .c file difference, keeping hardware platform dependant abstraction layer. Because Intel MCS51 (referenced as x51 in following text) platform is still quite popular in some circles and new MCUs can be bought quite cheap, keeping nice price/performance ratio, I decided to build programmer for it. I targeted at devices from Atmel, as those seems to be quite cheap and available. My idea was to make programmer, connected to serial port and waiting for Intel HEX file. Once received, it should program its content into target FLASH memory. No PC software needed, only serial terminal to send text file - throw hex file to serial port and you are done. Under linux, single cat command should be enough.

at89prog.zip

Source files for PIC89PROG, as MPLAB8 project, expecting XC8 compiler. Should port it to SDCC one day. Hex file included.

Zip Archive - 14.82 kB - 09/16/2016 at 14:04

download-circle
Download

schem.pdf

schematics in PDF format

Adobe Portable Document Format - 7.25 kB - 09/16/2016 at 14:04

eye
Preview
download-circle
Download

schem.sch

schematics in eagle sch format

sch - 82.67 kB - 09/16/2016 at 14:06

blank
See BOM
download-circle
Download

  • How it works

    jaromir.sukuba09/16/2016 at 13:55 0 comments

    AT89
    Most of Atmel FLASH x51 devices do have ISP capability, carried over SPI interface. That's the easy part. However, communication protocol is not exactly the same, greatly complicating programmer's software.
    I bought those parts: AT89S52, AT89S8253, AT89LP52, AT89LP51RB2, AT89LS52, AT89LP4052, AT89S2051 and AT89LP6440 and while browsing datasheets of those MCU I found out that there are virtually no two identical parts, when it comes to programming protocol.


    Programming hardware
    It is quite simple. One low-end PIC and serial SPI RAM. I decided to use external RAM because binary image of target memory could be quite huge (up to 64kB) and inernal RAM would be not sufficient. There is possibility of using MCU with more internal RAM, but those are made with 3,3V IO, so level converters would be needed. Writing FLASH of the target on the fly is possible, but due to different programming times and page size granularity for different MCUs it would need careful timing and selection of serial baud rate, so I opted for external RAM instead. The image is loaded into external SRAM and then handled as needed.
    As I did it in my STK500 project, whole thing is powered from target supply, operating in 3-5V range, so no level converters are needed. However, user has to be careful, as there is no overvoltage protection, so every mistake could be dangerous for programmer.

    Working with programmer
    It may seem to be a bit counter-intuitive, but once you get used to it, it's simple. There are only single letter commands (with no line end, only one ASCII character).

    h: print help
    a: toggle auto mode on(erasing-flashing target after receiving HEX file) or off
    p: toggle page sizes - 1B/32B/64B
    t: check target signature
    b: list buffer content
    r: list target memory content
    e: erase target memory content
    w: program target memory with buffer content
    v: verify target memory against buffer content
    l: toggle 89LP mode (mode 0 - no preamble, suitable for 89S52, 89S8253, 89LP52; mode 1 - 1 byte preamble, suitable for 89S2051; mode 2 - 2 byte preamble, suitable for 89LP51RB2, 89LP6440) Using l mode other than 0 keeps page size to 32B regardless of p setting.
    o: toggle reset logic (0 - active high, 1 - active low)


    Default reset values are: a - 1 (target is erased/flashed/verified after receiving HEX file into external RAM buffer), p - 1B (single byte write), o - 0 (reset is active high), l - 0 (no preamble mode).
    For example, working with AT89LP6440 needs setting to active high reset and 2 byte preamble mode, so after starting the programmer

    user needs to enter l twice (to toogle into mode 1 and 2) and o once (toggle reset polarity).

    Then, t should perform target test and print its signature.

    If everything is OK, programmer is set for programming session and ready to accept HEX file (Send file function or just copy file into tty device).

    Setting table for MCUs I programmed

    MCUlpo
    AT89S51/52010
    AT89S82530320
    AT89S2051/40510320
    AT89LP2052/40521x0
    AT89LS52010
    AT89LP52010
    AT89LP64402x1
    AT89LP51RB2/RC2/IC22x0
    I expect programmer to work with similar AT89 MCUs, however it was not tested.



    Conclusion
    AT89C MCUs are not that attractive nowadays and this programmer is more designer's joke than serious tool, but after all, it works as expected.
    Note that fuse and lock bit programming is not yet supported.

View project log

Enjoy this project?

Share

Discussions

esot.eric wrote 09/19/2016 at 05:35 point

Man... you've developed quite a stockpile of chip-programmers! I've got a few AT89?52's in the ol' collection, never got around to using 'em 'cause I ordered 'em thinking they were compatible with the P89C52 I used previously, but later found out their programming interface differed. Maybe "for Lulz" I should build this as my first 8-bit PIC project :)

You're well on your way to building The One Programmer for everything! Screw avr-dude, how about mcu-dude?

  Are you sure? yes | no

jaromir.sukuba wrote 09/19/2016 at 05:50 point

Thank you for your comment. I've got two more programmers in my drawer, getting ready for two new separate projects in here ;-)

I'm really thinking of merging it all together, but - perhaps due to my software architecture - it gets more difficult with more chips supported. I can see it at my #Microchip PIC Arduino based programmer project.

Another candidate to where all those programmers can be re-distilled is #Pavapro - portable AVR programmer I already started re-designing it with ARM micro, as the old AVR had only 20 bytes of FLASH left.

  Are you sure? yes | no

esot.eric wrote 09/28/2016 at 22:05 point

I dig it, man! And I know the joys of using up that FLASH :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates