simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] eeprom support


From: Theodore A. Roth
Subject: Re: [Simulavr-devel] eeprom support
Date: Mon Sep 30 21:04:04 2002

On Tue, 1 Oct 2002, Jason Kyle wrote:

:) At 12:17 1/10/2002, Theodore A. Roth wrote:
:) >Hi Alberto,
:) >
:) >On Mon, 30 Sep 2002, eban wrote:
:) >
:) >:) Hello everybody!,
:) >:)
:) >:) I'm trying to simulate a program that uses the
:) >:) internal eeprom and a external eeprom.
:) >:) At least I really need to use the internal eeprom.
:) >:)
:) >:) Simulavr has most of the work done to allow this, but
:) >:) i don't think there's a way to load my binary eeprom
:) >:) images yet.
:) >:)
:) >:) Is there a way to do this?
:) >
:) >Yes.
:) >
:) >:) How much work is needed?
:) >
:) >Oh, about 45 minutes worth. ;-)
:)
:) Far too quick, must be riddled with bugs!  Only hello world can be written
:) in 45min :)

Hey now, that included testing!

Actually the frame work was there, I just had to fill in the gaps.

<snip>

:) >:) What about the external eeprom?
:)
:) This really falls into the category of external periperals, much like a
:) dataflash memory would.  Can't see any really good reason for hooking up an
:) EEPROM to an AVR's external SRAM interface, perhaps you are meaning an SPI
:) or IIC bus EEPROM?
:)
:)
:) >Well, that's a bit more difficult.
:) >
:) >I'm assuming you are talking about memory mapping and eeprom device into
:) >the external sram space of the device. As far as I know, the AVR's don't
:) >have built-in support for external eeprom.
:) >
:) >Simulavr needs some serious work before could have this. :-\ It's on the
:) >TODO list, but I'm a bit busy with some other stuff right now. Feel free
:) >to dig into if you like. I'll help however I can.
:)
:) Would be cool to have an external periperal simulation interface, although
:) i'm sure it's been on your mind for simulavr's entire life it does
:) represent lots of work....  At your leisure :)

I think this is the single most requested feature, but also the most
difficult to implement in a sane way where you don't totally kill
performance. I'm constantly thinking about this, but just haven't stumbled
onto the best approach yet. I think refactoring some of the existing
subsystems might make the peripheral interface easier.

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]