On Mon, Jan 03, 2011 at 09:45:00AM -0500, Brian Gregory wrote: > In-Reply-To: <20110102172402.GB5850@mail.clayton.edu> >=20 > Byron, >=20 > > On Sun, Jan 02, 2011 at 04:42:35AM -0500, Michael Watterson wrote: > > > On 01/01/2011 23:45, Olin Lathrop wrote: > > > > Byron Jeff wrote: > > > >> > But how do you program it? I know the typical answer to this is= "buy a > > > >> > programmer". > > > > Exactly. It seems like you're going a long way to avoid getting a > > > > programmer. Do you realize a fully compliant programmer is now ava= ilable in > > > > singles for only $20 > > > > (http://www.microchipdirect.com/ProductSearch.aspx?Keywords=3DTEMLP= 001)? > > > > That's cheaper than I sell singles on my own web site. I'll make t= hem > > > > available at subtantial discount if you want to outfit a whole lab = or get > > > > one for every student in a class. Even before any educational disc= ount, > > > > it's already a lot less money than any book the student will have t= o buy for > > > > a class. > > > > > > > > The LProg only handles the PICs that can enter program mode with th= e unlock > > > > sequence and don't require high voltage on Vpp, but there are plent= y of > > > > those to chose from and that shouldn't be much of a constraint if y= ou're a > > > > hobbyist or student. > > > > > > > > Hopefully it will do the 16F182x subfamily soon. I'm digging thru = the > > > > normal high voltage programming algorithm now, and see that the POD= has been > > > > busy. It's mostly the same, but just different enough to require m= ore cases > > > > to be added in a few places. After I get the 16F182x working with = normal > > > > HVP on the USBProg, I'll try to add support to the LProg with LVP. > > > > > > > >> > But if you're only going to use it once in a blue moon, > > > >> > because the primary mode of development is a bootloader, it's n= ot as > > > >> > simple a decision as you may think. > > > > But you're only using the programmer once in a blue moon because it= kinda > > > > sucks, being a "dumper" as you call it. Think of the reverse. If = you > > > > already had a programmer then you wouldn't have to hassle with a bo= otloader > > > > at all. > > >=20 > > > Olin speaks great sense here. > > >=20 > > > If I was doing production programming I'd not recommend the Pickit2. = It=20 > > > and other budget programmers are for people that want to dabble and=20 > > > don't want to spend money. > > >=20 > > > As I had my own home made ICSP programmer (using VP=3D12V) and serial= port=20 > > > bitbanging for several years, I bought the Pickit2 at recommendation = of=20 > > > the list here as I needed 3.3V prog for 18FxxJxx family. I wish I had= =20 > > > bought it sooner. It was actually cheaper on Microchip site than clon= es,=20 > > > but delivery was 3 months. so I bought the clone from Sure Electronic= s=20 > > > (it matches Microchip published schematic) and it happily loaded the= =20 > > > latest firmware version from Microchip. You can pay MORE in the Retai= l=20 > > > High street for a dumb USB to Serial Adaptor. > >=20 > > Gentlemen, > >=20 > > Trust me when I say that there's more to the Universe than you show. > >=20 > > I've never been a fan of programmers, ICSP or otherwise. The required > > interface has always been restrictive, requiring a minimum of 3 I/O pin= s > > (and until recently 4 with LVP) to operate. A developer is either stuck > > impacting their target to accomodate ICSP or having to pull the chip in > > order to program it, which really sucks. > >=20 > > I thank Wouter for spoiling me rotten. With both WLoader, with its one = pin > > half duplex interface, and ZPL and its virtual zero pin interface, the > > programming interface becomes a single pin, or my choice, which usually= a > > pin that's out the way, instead of the top two pins of PORTB, possibly = the > > middle of PORTB, and MCLR, which is always shared with an input. Frank > > Sargent followed a similar route with his PikMe bootloader, making it > > bitbanged input only. For example on the 16F1939, MCLR is shared with > > PORTE3 as an input. The top pin of the last port is completely out of t= he > > way. > >=20 > > Take a read of Wouter's ZPL design document for a more detailed discuss= ion. > > I took the liberty of putting a copy on my site: > >=20 > > http://kahuna.clayton.edu/byron/zpl.pdf > >=20 > > Even though that was 8 years ago, all of his points are still valid: > >=20 > > - Chips are getting faster with more memory > > - I/O space and peripheral usage is at a premium > > - A transparent bootloader using simple interface hardware can be a > > useful development environment. > >=20 > > Now it's even better with embedded precision oscillators and actual I/O > > being shared on the MCLR pin. The programmer to the target becomes > > essentially a 2 wire interface that's completely out of the way of the > > application. And the single real cost, the program memory usage, is the > > real cost that can be easily absorbed. The 16F1939 I'm using now has 16= K > > words of program memory. A good bootloader will take up about 200 of th= ose > > words. > >=20 > > The final item is that no matter what type programmer you bring to the > > table, they are not going to be available off the shelf, and they only > > serve that one singular purpose of programming PICs. Even though they a= re > > similar in price, USB to serial converters are easily available, and th= ey > > can serve more purposes than just programming PICs. It may even be an i= tem > > that a new developer already has. > >=20 > > It's a viable development method, and there are valid reasons for pursu= ing > > it. ICSP just cannot ever be as transparent as a bootloader can be. > >=20 > > BAJ > >=20 > > --=20 > > Byron A. Jeff > > Department Chair: IT/CS/CNET > > College of Information and Mathematical Sciences > > Clayton State University > > http://cims.clayton.edu/bjeff > > >=20 > But how do you do your debugging? Good question. I have two primary methods: 1) Simulation. I use the gpsim simulator to do overview testing. It usually catches the obvious errors and gives a good first crack at working software. 2) Serial debugging through the bootloader port. There is a serial interface that's available via the bootloader pin(s). And the bootloaders serial read/write routines are available for me to use. So I simply print messages, data, status through that serial port once I get the application on the chip. As stated elsewhere I'm not a Windows guy. I haven't used MPLAB since the DOS days of the mid 1990's. Chips that I used before PICs, like the Motorola 68K family did not have hardware debugging either. So I never missed something that I never had. It makes little sense (for me, for me, for me, and FOR ME!) to flip my entire setup to run a single application so that I can get hardware debugging. I know some developers that do (i.e. keep a DOS machine around to run a single app for example). Doesn't happen to be my style. So I adapt whatever tools I have available to fit the environment I'm using. BAJ --=20 Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .