Shop OBEX P1 Docs P2 Docs Learn Events
.binary vs .eeprom? — Parallax Forums

.binary vs .eeprom?

mparkmpark Posts: 1,318
edited 2008-10-22 23:11 in Propeller 1
OK, stupid question time:

What is the difference between a .binary file and a .eeprom file? When would you choose one over the other?

I only ever use .eeprom but I'd like to expand my horizons.

Comments

  • tpw_mantpw_man Posts: 276
    edited 2008-10-05 00:32
    I believe there is no difference, except that the .eeprom contains basically a mirror image of the RAM at download, and .binary only contains the defined stuff. (up to the $FFF9FFF9)

    EDIT: In practice they are the same and do the same thing, except they are sized differently.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I am 1011, so be surprised!


    Advertisement sponsored by dfletch:
    Come and join us on the Propeller IRC channel for fast and easy help!
    Channel: #propeller
    Server: irc.freenode.net or freenode.net
    If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
    tongue.gif
  • Luis DigitalLuis Digital Posts: 371
    edited 2008-10-05 02:16
    EEPROM file has verification of data, if there are corrupt data there will be a notice.

    Binary files are data and nothing more.
  • tpw_mantpw_man Posts: 276
    edited 2008-10-05 02:21
    @Luis Digital
    I do not think that is true because a checksum is standard in the binary header, which contains other important info such as the clock frequency and starting addresses.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I am 1011, so be surprised!


    Advertisement sponsored by dfletch:
    Come and join us on the Propeller IRC channel for fast and easy help!
    Channel: #propeller
    Server: irc.freenode.net or freenode.net
    If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
    tongue.gif
  • Luis DigitalLuis Digital Posts: 371
    edited 2008-10-05 02:54
    Ok, then the files .hex have double checksum in this case.
  • BradCBradC Posts: 2,601
    edited 2008-10-05 05:09
    No they don't. There is only one checksum in the file.

    A binary file is the header and the code only. It ends at VBASE-1. An EEPROM file is the entire Image as the prop would write it to the EEPROM.
    If you are downloading to a prop, it's much faster to just download the binary, the Prop bootloader will fill in the rest.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-10-05 12:29
    Agreed, there is only one checksum in the file and it is the same regardless of whether .binary or .eeprom file. It is a checksum of the entire 32KB image, with variables and stack space set to zero and the $FFF9_FFFF base of stack markers in place for an expanded .binary file.

    What actually gets sent to a Propeller chip on download depends on the downloader itself. A .binary file could be expanded to 32KB and sent as a full 32K bytes, a .eeprom file may only have the image up to VBASE sent, or it may be that every byte of the 32KB image is sent up to its last non-zero long.

    For the Propeller chip itself, it takes as many longs as it is told to, fills from $0000 upwards, pads the rest of the image with zeroes, places the $FFF9_FFFF markers, calculates the checksum of the entire 32KB then checks it is correct, aborting if it isn't.

    In normal use it shouldn't matter whether .binary or .eeprom is used. The only time it may matter is if altering the image at or above VBASE after it has been generated and saved. What happens then ( whether an extended .binary, a .eeprom, or other file ) depends on what the particular downloader does when loading the file, whether it loads the file "as is" or only loads image up to VBASE.

    Whether there's any integrity check that a .binary or .eeprom file as it would be as generated depends on the particular downloader.

    What we do have is knowledge of the .binary and .eeprom file formats as generated and knowledge of how the Propeller Chip downloader works. What I don't have is full knowledge of how the PropTool and Propellent downloaders ( or others ) handle the files or what they actually send to the Propeller.

    Post Edited (hippy) : 10/5/2008 12:36:23 PM GMT
  • BradCBradC Posts: 2,601
    edited 2008-10-05 12:33
    hippy said...
    What I don't have is full knowledge of how the PropTool and Propellent downloaders ( or others ) handle the files or what they actually send to the Propeller.

    That bit I can help with, as my little ploader pretends to be a propeller and lets propellent or proptool download to it's pseudo serial port.
    Give me a couple of days and I'll be able to tell you precisely what they do.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pull my finger!
  • hippyhippy Posts: 1,981
    edited 2008-10-05 12:37
    @ BradC : Excellent. I retracted my statement about only ever downloading to VBASE, because I'm moving the stack and inserting bytecode where it was and PropTool has downloaded that from a modified .eeprom file.
  • pemspems Posts: 70
    edited 2008-10-22 20:41
    I've noticed something curious as i was creating my own loader from a standalone MCU connected to prop.

    The .binary only seems to have bytes up to and not including the yellow section of the hex object info (i am guessing these are SPIN variables?)

    So the curious thing that i've realized is that the checksum is not just a checksum of the program bytes (i.e everything before the yellow section) but also the stuff in the stack (i.e the FF's and F9's)
    The way i realized that is i was wondering why the heck the checksum doesn't add up and leaves a value of 0x14 (20) instead of expected zero, after adding all of the bytes in .binary

    i found this doc which is pretty good, but i still don't understand what those ff's and f9's are in the two words of the stack space

    http://forums.parallax.com/forums/attach.aspx?a=16010
  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-10-22 23:11
    The first entry in the stack is a fail safe mechanism in case the top level routine returns, it will cause no harm (it just shuts down the cog).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
Sign In or Register to comment.