Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

Hi all, I am working on a program, and I want to store some data (on the order of a couple hundred bytes) in the EEPROM space on a BX-24. I know how to do it... I just don't know where to do it. What is a good memory location in the EEPROM to put small blocks of data like this? Later, Jon

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

There are some examples at http://www.phanderson.com/basicx/ As I recall, there is an example of a daat logger that uses on-board EEPROM. The one thing you want to be careful of is to use EEPROM which is at a higher address than your program. But, with 32K of EEPROM, this sure isn't much of a problem. Peter H. Anderson, Morgan State University , http://www.phanderson.com -----Original Message----- From: Jon Hylands <> To: <> Date: Monday, May 29, 2000 5:54 PM Subject: [BasicX] EEPROM Storage Question : :Hi all, :

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

On Mon, 29 May 2000 18:03:59 -0400, you wrote: > As I recall, there is an example of a daat logger that uses on-board EEPROM. Thanks Peter, I guess I saw that before, but didn't really read it :-) BTW, I have successfully written a more-or-less proper Dallas 1-wire interface now, complete with SearchROM and also checking for the presence pulse to ensure there are 1-wire devices attached and working. Due to the limits on passing multi-dimension arrays, and the limits of GetBit and SetBit, I am going to store the ROM ids in EEPROM, and use them from there. Otherwise, I am stuck with only supporting four devices on the bus. The SearchROM routine I have written is generic, and can support an arbitrary number of devices, once I get the memory issue taken care of. Once I've got it fixed to use EEPROM to store the ROM id, I'm going to write a separate module for accessing the 1820 termperature probe, using the generic 1-wire module. I think it is important to separate the generic five functions (Read, Match, Skip, Search, and Alarm) for all 1-wire devices from the device-specific routines, since there are so many different 1-wire devices, and they all have different device-specific commands. Anyway, once I get that done, I'm going to post the code, and hopefully people can bang on it and make sure it actually does what it is supposed to do, especially since I currently only have two 1820s to test it with :-) Later, Jon

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Peter H. Anderson < > [...] The one thing you want to be careful of is to use > EEPROM which is at a higher address than your program. > But, with 32K of EEPROM, this sure isn't much of a problem. Another possibility is to use one of the block data classes, the advantage being that the compiler automatically allocates EEPROM memory. Plus you can choose either read/write or read-only access to the memory block. The block also shows up in the MPP map file, BTW. -- Frank Manning -- speaking only for myself

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

On Mon, 29 May 2000 16:27:07 -0700, you wrote: > Another possibility is to use one of the block data classes, the > advantage being that the compiler automatically allocates EEPROM > memory. The only question with these is can I move arbitrary subsets of data from the block/array to a RAM variable? For doing bit-level operations, I think accessing and modifying EEPROM would be a mistake. I really need to have two 64 bit arrays in RAM to work from, and then cycle them into EEPROM when I am done with them, and move on to the next device. Later, Jon

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

From: Jon Hylands < > On Mon, 29 May 2000 16:27:07 -0700, you wrote: > > > Another possibility is to use one of the block data > > classes, the advantage being that the compiler > > automatically allocates EEPROM memory. > > The only question with these is can I move arbitrary > subsets of data from the block/array to a RAM variable? Sure. That's what the DataAddress property is for -- check out the Operating System Reference, p. 8. You can use DataAddress in conjunction with GetEEPROM and PutEEPROM for low-level access. > For doing bit-level operations, I think accessing and > modifying EEPROM would be a mistake. I really need to > have two 64 bit arrays in RAM to work from, and then > cycle them into EEPROM when I am done with them, and > move on to the next device. You could use GetEEPROM to copy 8 bytes from EEPROM to RAM, then use GetBit/PutBit to access individual bits in RAM. Afterwards, PutEEPROM could be used to write the data back to EEPROM. -- Frank Manning -- speaking only for myself

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

On Mon, 29 May 2000 17:20:15 -0700, you wrote: > You could use GetEEPROM to copy 8 bytes from EEPROM to RAM, then use > GetBit/PutBit to access individual bits in RAM. Afterwards, PutEEPROM > could be used to write the data back to EEPROM. Yeah, that's what I ended up doing, and it works great :-) Later, Jon

(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )