#23 [RFE] proper emulation of EEPROM support

open
nobody
None
5
2007-02-26
2007-02-26
Anonymous
No

Currently, EEPROM support seems to be limited to the currently active session, that is unlike an actual EEPROM, gpsim core don't seem to support persistence for data stored in memory regions designated as "EEPROM".

I think it would add a good amount of realism, if gpsim could optionally support inter-instance persistence for EEPROM data.

Something like this could probably be easily achieved by simply serializing the corresponding bytes to a simple ASCII file (i.e. simply write the hex values as memory/data pairs: 0x00:0xFF, 0x01:0xCD, 0x02:0X02 etc.).

This ASCII file could then -for example- be referenced in the assembly file by using a corresponding pre-processor directive, or alternatively simply by providing a corresponding new switch to gpsim during startup.

Of course, different PICs have different requirements, so saving some additional meta information, might also be a good idea (i.e. type of PIC, so that the valid memory ranges/addresses can be derived, and possibly show a warning if an EEPROM data file contains value pairs for memory locations that aren't valid for that particular PIC).

Discussion

  • Nobody/Anonymous

    Logged In: NO

    couldn't you embed this sort of info directly in the COD file?

     
  • Nobody/Anonymous

    Logged In: NO

    if something like this is added, providing separate commands to load/unload files from the CLI should also be considered, also having a separate command to fill a memory region with values (i.e. to clear it) would also be useful, so that the eeprom data could be easily modified from within the simulator in debugging sessions.
    In that respect, it's also worth to note that other debuggers often feature some simple calculator mode where arbitrary values can be converted to/from dec,hex,oct,bin - I feel, that having something like this would also be useful to have in order to easily deal with different representations of otherwise identical data, OTOH something like this might in fact be a good candidate for implementation as a custom command, via some sort of standalone script as suggested in the other suggestion?
    Besides, I'm not so sure if a BINARY file format shouldn't be preferred over ASCII for the obvious reasons-of course, ASCII files are somewhat easier/more intuitive to debug/modify, but as long as gpsim provides a corresponding interface to such binary EEPROM dumps, there should be hardly any drawbacks associating with directly using a binary format.

     
  • Nobody/Anonymous

    Logged In: NO

    while the suggested approach would certainly be an interesting feature, I suggested in a different thread yesterday to consider using VHDL in order to describe PIC/micro-controller peripherals, this would not only be more powerful and generic, but would also be interesting for other purposes, too: for example, eventually you may no longer want to only emulate controller-peripherals (integrated ones) but rather add external chips, like i.e. an EEPROM or SRAM which may interface with the emulated PIC. By using an VHDL-oriented target description language, this would automatically be a re-usable solution for such and similar solutions

     
  • Nobody/Anonymous

    Logged In: NO

    FWIW, VHDL specifically supports file I/O stuff for emulation purposes.

     
  • Roy Rankin

    Roy Rankin - 2007-09-12

    Logged In: YES
    user_id=992727
    Originator: NO

    The commands dump e and load e now exist in gpsim(in the latest SVN).
    The dump command can be used to save the contents of either the processor or module EEPROM into a file in Intel hex format.
    The load command can then be used to load the contents of the EEPROM from the Intel hex file.

     
  • Nobody/Anonymous

    Logged In: NO

    so is there also a way to automatically have this done in the background, to emulate eeprom-persistent data across different sessions?

     
  • Nobody/Anonymous

    Logged In: NO

    regarding the use of VHDL to describe PIC targets, you may want to look into GHDL, the open source'd/GPL GNU VHDL compiler

     
  • Nobody/Anonymous

    Logged In: NO

    FYI:http://www.itstudy8.org/ShowBook.asp?BookId=2626

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks