On Wed, Feb 18, 2004 at 09:03:56AM +0100, Wouter van Ooijen wrote: > > My initial target is going to be the 16F819. I really want to > > see if the > > bootloader is stable when using the internal osciallator module. > > One thing I noticed with a scoop hookep up is that the resistor from the > transistor's base to ground is realy needed and must be ~ 1k, 10k > results in a too-slow switching off. No problem. That should provide enough base current for a fast turn off. I usually use 1k resistors with 2N2222 style PNPs anyway. > If you want to use the internal osc > you might need a lower value pull-up resistor than I recommend, maybe 1k > too. Definitely will. Helpful because I have a whole roll of 1Ks in my box. > > I agree to a point. However the 16F88 is looking real sweet > > right now for > > the hobbyist. Real UART, real A/D, nanowatt enabled, self > > programmable, 4K > > program space, 18 pin package. Only $2.60 USD in quantity. It > > would be a > > excellent target for a hobbyist, especially if it had a ZPL > > bootloader in it. > > Maybe for a DIY-starter. But note thate an 18F252 (16k code, 28 pins) is > only ~ twice that price. Help me out with the 18F. I have a few issues. Care to address them? 1) Programming infrastructure support. As I stated I'm working on updating my picprg to work with newer PICs. I finally figured out that pretty much all of the 14 bit cores use the same programming and erasure algorithms, with only the delay times and block size parameterized. But the 18Fs are a completely different animal. So programmers that support it in the homebrew arena are coming up slower. I know that Wisp628, PikDev, and I believe Odysessey have such support so it is coming along. 2) Software infrastructure support. I haven't checked the state of the programming languages lately but other than assembler, what has full 18F support and is available for alternative platforms such as Linux? I've turned over the NPCI project to Brad Parker who said he'd tackle getting a 18F bytecode interpreter (which I had started but hadn't finished or tested) going. Where is JAL, XCSB, SDCC, and the like in terms of 18F support? gpasm works fine of course, but as you well know it's easy to get spoiled by having high level languages available. I'm sorry I haven't researched this question and find out the answers for myself. 3) Tutorial/Example infrastructure. Sure the 18F is better (actually see point 4 below), but how many examples/tutorials/running code can you find for it. Consider Fr. McGahee's PICUART tutorial/code. A brilliant example of how to leverage real code to show how the PIC serial interface works warts and all. Is there a similar 18F version? Is there examples of how to really utilize all the cool 18F features like the less segmented memory space, branch instructions and the like? 4) Silicon issues. Not running at the full 40 Mhz, PLL issues, and the like. I get the willies when the erratta sheet states that operation faster than 4 Mhz is not guranteed. While the 16F does has it quirks (pulling down the LVP pin even when LVP mode is disabled for example) it's pretty stable. Anyway getting up to speed with the 18F series is in the cards and you have helped by providing my perferred programming environment. I have some 18F1320s and 18F452s in stock and getting some 18F4320s too. Once I get picprg stabilized with the newer 16Fs (16F87XA and 16F819 have been tested and they work), and get a preliminary ZPL going, I'll come back to them again. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.