gnupic: [gnupic] GPSIM / dsPIC / SPI
Subject:
[gnupic] GPSIM / dsPIC / SPI
From:
"Andrew Nguyen" ####@####.####
Date:
17 Jan 2006 15:36:45 +0000
Message-Id: <A79EE6739F2C7348A857541FB5CD92D60203376E@asimail1.rb.uav.com>
Thanks for the heads up. As an aside, could the existing infrastructure
support a SPI module? I remember reading that a SPI module hadn't been
added to gpsim yet.
--Andrew
> -----Original Message-----
> From: Scott Dattalo ####@####.####
> Sent: Tuesday, January 17, 2006 07:14
> To: ####@####.####
> Subject: RE: [gnupic] GPSIM / dsPIC
>
> Hi Andrew,
>
> I can tell you whatever you need to know about gpsim!
>
> I was going to suggest the .hex route for loading the source too as a
> first step. This will solve the problem of having to parse the object
> files. However, eventually you're going to have to have symbols...
>
> As far as gpsim's architecture, currently all three families
> of the PIC
> processors are supported: 12-bit core, 14-bit core, and
> 16-bit core. Even
> the old 16-bit core (17C series) has some support. In addition, I've
> ported gpsim over to some proprietary microcontrollers (that are
> substantially different than PICs). I'm confident there's enough
> infrastructure to support the dsPIC.
>
> gpsim is written in C++. There are classes for processors, registers,
> instructions, peripherals, breakpoints, etc, etc. It can get quite
> overwhelming to learn how these are all interconnected. So
> it'd probably
> make sense studying the 16-bit port to get some idea of what
> to do for the
> dsPIC port. The files to look at are src/16bit-processors.cc,h ,
> src/16bit-registers.cc,h , src/p18.cc,h , src/16bit-hexdecode.cc, and
> finally src/16bit-instructions.cc,h.
>
> Please feel free to ask any questions. Meanwhile, I'm going
> to take a peek
> at those links Xiaofan posted.
>
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
