---- START NEW MESSAGE --- Received: from cherry.ease.lsoft.com [209.119.0.109] by dpmail10.doteasy.com with ESMTP (SMTPD32-8.05) id A4DCE770230; Thu, 29 Jan 2004 10:45:48 -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 <12.00CC300F@cherry.ease.lsoft.com>; Thu, 29 Jan 2004 13:27:36 -0500 Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e) with spool id 7979 for PICLIST@MITVMA.MIT.EDU; Thu, 29 Jan 2004 13:27:30 -0500 Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 7088; Thu, 29 Jan 2004 13:16:44 -0500 Received: from mxsf25.cluster1.charter.net [209.225.28.225] by mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with ESMTP ; Thu, 29 Jan 2004 13:16:43 EST X-Comment: mitvma.mit.edu: Mail was sent by mxsf25.cluster1.charter.net Received: from 209.225.8.224 (dc-mxdb09.cluster1.charter.net [209.225.8.84]) by mxsf25.cluster1.charter.net (8.12.10/8.12.8) with SMTP id i0TIFRIS051810 for ; Thu, 29 Jan 2004 13:15:27 -0500 (EST) (envelope-from drrdr@charter.net) X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <200401291815.i0TIFRIS051810@mxsf25.cluster1.charter.net> Date: Thu, 29 Jan 2004 18:15:27 +0000 Reply-To: pic microcontroller discussion list Sender: pic microcontroller discussion list From: Rick Regan Subject: [PIC]: PIC16C745/65 Hi-Tech C USB firmware: bank 2 vs. bank 3 To: PICLIST@MITVMA.MIT.EDU Precedence: list X-RCPT-TO: Status: U X-UIDL: 371856303 I don't know if there are any of you out there that have looked at the Hi-Tech C USB firmware (version 2.00) for the PIC16C745/65, but I figured I'd ask a question about it just in case. The buffer descriptor table (BDT) lives in bank 3 at 0x1A0, but the code declares it in bank2 (with the 8-bit offset of 0xa0): bank2 struct BufferDescriptorEntry * BDT= (struct BufferDescriptorEntry *)0xa0; In the "TokenDone" routine, the BDT is accessed with these lines of code: BDTCopy.EPStat = BDT[USTAT/4].EPStat; BDTCopy.address = BDT[USTAT/4].address; BDTCopy.bytes = BDT[USTAT/4].bytes; If you run it in the simulator, you can see that BDTCopy is filled in correctly, meaning that the BDT is read from bank 3 (I manually set values in the BDnd* registers beforehand to verify they were copied). Looking at the generated code, the IRP bit in STATUS is set, which puts it (correctly) in bank2/3. Does anyone know why they did it this way? Why didn't they just declare it in bank 3? I tried that and it worked (in fact, the hex files were identical). Rick -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. .