From PICLIST@MITVMA.MIT.EDU Thu Nov 14 06:24:49 2002 Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-7.13) id A231116700EC; Thu, 14 Nov 2002 06:24:49 -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 <10.007D5673@cherry.ease.lsoft.com>; Thu, 14 Nov 2002 9:10:58 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 4162 for PICLIST@MITVMA.MIT.EDU; Thu, 14 Nov 2002 09:07:12 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 8672; Thu, 14 Nov 2002 09:06:29 -0500 Received: from mta05-svc.ntlworld.com [62.253.162.45] by mitvma.mit.edu (IBM VM SMTP Level 320) via TCP with SMTP ; Thu, 14 Nov 2002 09:06:29 EST X-Comment: mitvma.mit.edu: Mail was sent by mta05-svc.ntlworld.com Received: from m128-mp1.cvx1-a.pop.dial.ntli.net ([62.255.68.128]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021114140625.FPAZ26478.mta05-svc.ntlworld.com@m128-mp1.cvx1-a.pop.dial.nt li.net> for ; Thu, 14 Nov 2002 14:06:25 +0000 References: <3DD33141.52D59C2A@3mtmp.com> <002601c28bdc$817cc920$b64aa40a@gm> <000601c28be1$c109c2a0$8698ab41@THSystem> X-Mailer: Forte Agent 1.9/32.560 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <41b7tuo7hc6l1sai0r8d7nblahv013a2t4@4ax.com> Date: Thu, 14 Nov 2002 14:06:04 +0000 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Mike Harrison Organization: White Wing Logic Subject: Re: [PIC]: Detecting SRAM and eeprom To: PICLIST@MITVMA.MIT.EDU In-Reply-To: <000601c28be1$c109c2a0$8698ab41@THSystem> X-RCPT-TO: Status: R X-UIDL: 277600456 X-Evolution-Source: pop://mailinglist%40farcite.net@mail.farcite.net/ X-Evolution: 000006b0-0000 The exact method depends on how your address decoding works, e.g. whether unused areas read 'blank', i.e. whatever the bus floats to, or as 'echoes' of the areas present.=20 A fairly general-purpose approach to both detecting and testing RAM is to write a byte comprising the sum of the high and low bytes of the address to each location. Summing the address bytes catches any address-line faults. For detection, you just read back and verify the pattern, and when its stops verifying good, that's the end of the fitted memory. This will catch all address/data line fauilts. For a more thourough test coverage, repeat the process with the byte pattern inverted - this will detect stuck bits. If you just want detection, you obviously don't need to write to all locations, just the ones whose presence will change with differing configurations.=20 . On Thu, 14 Nov 2002 07:28:43 -0600, you wrote: >Ok, > >I've been thinking about this for a few days now and am not sure how to do >it. > >Let's say I have a little thing built that logs data - it requires externa= l >SRAM, and external eeprom (SRAM for temp storage, and eeprom for long term >of a givin block of data for later download). > >I need to be able to auto-detect how much SRAM is available (ie: 0, 16, 32= , >64Kx8bits, 1 or 2 chips) and how much eeprom (if any) is available (1 or 2 >chips). > >I really am not sure how to do this, so any suggestions would be most >appreciated. > >I'm just not suere where to start. I'm planning on using parallel ram, >address lines A0 - A15 (want expandibility ;), with 8 bit for data. > >So, to sum up - I need to see if there are any chips there, and if there >are, how much data can be stored. > >Thanks in advance! > >-Tony -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics