On Sat, Aug 27, 2005 at 09:58:21PM +0800, Chen Xiao Fan wrote: > I think the most important thing is to open > up the MPLAB ICD2 protocol (programming and debugging). > That is the single most important hindrant for dsPIC > development under Linux. Why? There are already software and programmers and bootloaders for developing the dsPIC on Linux. Obviously as a 100% Linux user, the ICD2 is completely out of my scope. So if you have a minute, explain what does it bring to the table. > > To provide C30 buidling insturction (without the > close source optimizer) and packages will be another > good thing to do. That's been done by someone else. You've posted the links to it. MChip has been very very gracious in sticking to the GPL and releasing the source for C30. The Linux community doesn't need them to be the developer for that community. > To offer financial support to key > developers are also quite nice but I understand > that some of the developers may not want this kind of > support. What's the benefit to MChip to add money to the situation? There simply isn't enough of a customer base to justfy spending any money. Frankly it's a foolish endeavor to invest money with no apparent ROI to developers who would in fact do it for free. With C30, quid pro quo has already happened. MChip didn't have to start building a compiler/assembler from scratch. The community gets the benefit of the changes and additions to the base that MChip started from. That's how it's supposed to work. And it is working. > > I think there are other things they can do better. I am > very satisfied with Microchip's support for my > projects in my work and I am not saying that Microchip > is doing quite badly in supporting the open source > community. As you said, they are quite good. I am > very new to PIC development on Linux (my first two posts to > GNUPIC mailing list are about LPLAB testing on Linux > and MPLAB under Linux with Wine on May 26, 2005) and > I think I've already have a working enviroment under Linux > similar to Windows with gputils/gpsim/sdcc/C18/C30. > That is quite good. Bingo. After fighting battles with other companies simply to get enough information to do implementation, MChip is quite a refreshing change. > However as Wouter and others have > said, Microchip can do better to foster the support of > dsPICs (including dsPIC development on Linux). They have. You can do dsPIC development on Linux. It may be nice if they released a subset of the dsPIC library under an Open Source license. But there are already free C libraries out there. Why can't they be adapted to the C30 compiler? >From a business perspective, MChip gains little from supporting Linux in any substative way. They should continue doing what they have been doing up until now: plant cheap seeds that have little development and support cost, and see what pops up. > I still do not have my ICD2 working under Linux even > though PICkit 1 is working and hopefully PICkit 2 will > soon work under Linux as well. Interface specs would be nice. But as I pointed out before, MChip opens themselves up to support headaches whenever they release an interface spec for their product. In addition to cloning, they then have to deal with issues when some 3rd party software causes a problem with their ICD2. The other issue is that whenever you Open Source release, the code has to be reasonably clean. I'm not sure how to resolve it. Why not ask them for an interface specification for the ICD2 and see what they say? > Of course I am only a part-time Linux guy and I can always > boot back into Windows to have my ICD2 working if I mess up > my PICkit 2 and needs to reflash the flash. However there are > people who do not have Windows. Like me. Of course I don't have an ICD2 either. I have a tough time justifying plunking down $160 when a Tait style programmer, some existing software, and the potential for bootloading are all already on the table. MChip has already contributed greatly because they put free dsPIC samples in my hands. > Even if there are cheaper programmers which support dsPICs on > Linux and if people can extend the bootloader by Daniel Chia and > the Tiny Bootloader, still the debugging will be an issue. Xiaofan, I've been in the embedded systems game for close to 20 years now. While hardware level debugging is certainly convenient, it's not a required tool for successful development. > So open up the ICD2 protocol will one thing they can help > a lot. That is kind of critical info, right? Debateable. > They can always keep the protocol/API close for the expensive > ICE2000/ICE4000. :) I'm playing devil's advocate for Microchip. They have a complete environment that the ICD2 works in. I see no benefit to them to open the interface spec up. Can you name one? BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist