From PICLIST@MITVMA.MIT.EDU Fri Nov 15 01:46:19 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A26B120100B0; Fri, 15 Nov 2002 01:46:19 -0800 Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.007DB395@cherry.ease.lsoft.com>; Fri, 15 Nov 2002 4:32:13 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 0199 for PICLIST@MITVMA.MIT.EDU; Fri, 15 Nov 2002 04:31:58 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 5358; Fri, 15 Nov 2002 04:29:36 -0500 Received: from lmail.actcom.co.il [192.114.47.13] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with ESMTP ; Fri, 15 Nov 2002 04:29:35 EST X-Comment: mitvma.mit.edu: Mail was sent by lmail.actcom.co.il Received: from plp.plp.home.org (p14.ta6.actcom.co.il [192.115.24.14]) by lmail.actcom.co.il (8.11.6/8.11.6) with ESMTP id gAF9TXh14731 for ; Fri, 15 Nov 2002 11:29:34 +0200 Received: from plp.plp.home.org (plp.plp.home.org [192.168.0.1]) by plp.plp.home.org (Postfix) with ESMTP id E4AAFA4915 for ; Fri, 15 Nov 2002 10:04:57 +0200 (IST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 15 Nov 2002 10:04:57 +0200 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: "Peter L. Peres" Subject: Re: [PIC]: Detecting SRAM and eeprom To: PICLIST@MITVMA.MIT.EDU In-Reply-To: X-RCPT-TO: Status: R X-UIDL: 277600613 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 0000073d-0000 On Thu, 14 Nov 2002, Dale Botkin wrote: *>On Thu, 14 Nov 2002, Peter L. Peres wrote: *> *>> For ram: reserve two adjacent locations for each block (page) you may use. *> *>Or not: *> *>Read location XX *>Save original value *>XOR data read with 0xFF *>Write XORed pattern to loction XX *>Read location XX *>See if it's what you wrote (if so, it's RAM/EEPROM) *>Write original contents back to location XX *>Increment XX by some value, like 256 or whatever. The problem is in the read after write to the same location. On many cmos buses the bus capacitance will store state between the read and write and the test will succeed even if there is no part at that address. I did not dream this up, it really happens all the time and I do take this into account. You have to write twice to be able to test, there HAS to be a write with a different value than the test location's before you read the test location again. Otherwise it will not detect an empty socket. You could use xor like this: success = 0; LOCK; t = [a] = [a]^0xA5; [b] = [b]^t; // [b] != t if([a] == t) success = 1; [a] = [a]^0xA5; [b] = [b]^t UNLOCK; LOCK/UNLOCK are needed with concurrent programming. Peter -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.