Allow me to translate: "We made the decision some time ago not to try to simulate all of the peripherals of the chip with MPLAB-SIM." Read: The suits won't let us write something that might cut into emulator sales and increase tech support issues from non-professionals without an off-setting revenue stream. Its easier to tell people that they need an emu or ICD when they get to that level of coding. Really, they would like to just say it can't be done and insist on selling an EMU. They don't like the ICD concept and don't want it to become as open and cheap as it could be because then all the little guys would start trying to write stuff and we couldn't offset the tech support against development tool sales. It was everything we could do to convince them that if we didn't answer Scenix with the '877 ICD ability we would start really loosing the (small but significant) grassroots market. The extra cost of the hardware on every production chip is impossibly to justify to our big customers who are used to EMUs' and don't care so much about the cost of development support. The only reason its flying so far is that its nice to be able to troubleshoot a production part in situ. "We don't have the staff to even make the attempt." Read: We don't see it as being an important issue except to little guys like you who can't afford an EMU. And all you guys together don't buy enough chips to pay for the extra programmer time. If a major user decided they were going to switch processors 'cause we don't simulate USART interrupts, it would be in there so fast your head would spin, but you would still probably never see it. "The GNUPIC project, which I fully support" Read: I also get sick of writing what the suits tell me to write. As long as it doesn't cost me my job, I'm rooting for you. "the code is mostly in a DLL, is object-oriented" Read: If you want to reverse engineer the connection from the GUI to the core simulator, so that you can extend it by picking off events and handling them yourself, it would be entirely possible and I'd be happy to help but I can't come out and say that 'cause the suits are watching. This translation is based on my years of experience with an e-commerce retail software house and may not be totally accurate. Believe it or not, I'm not trying to bash Microchip here... I think they are a great company. It's just that some people may not be aware of the internal issues involved in running a company like this and I though it would be interesting to try to guess at some of them based on my previous (similar) experience. I'd be happy to hear corrections and rebuttals. --- James Newton mailto:jamesnewton@geocities.com 1-619-652-0593 http://techref.massmind.org NEW! FINALLY A REAL NAME! Members can add private/public comments/pages ($0 TANSTAAFL web hosting) -----Original Message----- From: pic microcontroller discussion list [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Darrel Johansen Sent: Tuesday, March 07, 2000 06:06 To: PICLIST@MITVMA.MIT.EDU Subject: Re: PIC18CXXX Assembler? & MPSIM Robert, I make no secret of my "inside connections" to Microchip. I post here from my home account and from my Microchip mail address. We made the decision some time ago not to try to simulate all of the peripherals of the chip with MPLAB-SIM. There are too many subtleties that would just be misleading and we don't have the staff to even make the attempt. As a result, the simulator is an instruction based simulator. It does not have the resolution to be able to handle the various peripherals accurately. The GNUPIC project, which I fully support has made strides toward some of these goals If it's mainly the simulator that your are interested in, the code is mostly in a DLL, is object-oriented, and, if people wants to spend the time on it, we could do a trial run to see what happens. Might be fun. Darrel ----- Original Message ----- From: "Robert Rolf" To: Sent: Monday, 06 March, 2000 11:48 PM Subject: Re: PIC18CXXX Assembler? & MPSIM > Darrel Johansen wrote: > > The 18Cxxx assembler is in the "dot" release of MPLAB on the Microchip web > > page (currently v4.99.07). The linker and simulator also support the chips, > > and header files and linker scripts are included with MPLAB. MPLAB v5.00 > > will be posted soon (this week) and all current tools will support the > > 18Cxxx devices. MPLAB-ICE support is in beta and will be fully released in > > v5.10. > > > > Darrel Johansen > > So Darrel, since you seem to have some inside connections, when > might we expect to see some support for the devices -already in- > the _existing_ chips?? Simple things like the USART, MSSP, etc. still > don't have working support in MPSIM. It can't be -that- hard to simulate > USART interrupts (a common use of the USART). > > As Microchip adds all these nice new chips to their product line it sure > would be helpful to be able to debug code before the silicon comes out. > > Has Microchip considered releasing the source to MPLAB under terms > similar to the GNU public license? I'm sure that many of us would > be quite happy to 'fix' the broken bits that they obviously don't > have time to work on. > > Robert.Rolf-at-UAlberta.ca >