On Mon, Aug 05, 2002 at 01:23:57PM -0400, myke predko wrote: > Hi Folks, Hey Myke! > From: "Alan B. Pearce" > > As you are suggesting having a CD in the box, is it worth getting > permission > > from appropriate places to redistribute the MPLAB environment, and maybe > the > > HT-Lite C compiler on it? You would need to include the necessary web > links > > to the original sites on some form of documentation page, but this could > be > > an html page on the CD anyway. > > This is not trivial. Microchip is very difficult to work with in getting > permissions for placing their tools and datasheets on third party works. > Depending on the situation, it would save a lot of hassle just by pointing > to http://www.microchip.com. That's going to be a tough problem. I'm not sure we can presume that everyone who wants the kit will have effective Internet access. It always give me a small chuckle because I use the gputils tools. But it's an issue we're going to have to address somehow. > > > From: "Byron A Jeff" > > Actually I'd take an entirely different tack. I'd like to see: > > > > * A 16F876 or 16F877 with a bootloader in it. > > * A MAX232 serial interface. > > * Onboard single LEDs, a couple of 7 segments, and an LCD, each with > jumpers > > so they can be disabled. > > * A couple of buttons, a pot, and an opamp for A/D experiments. > > * Jacks for ICSP and external I/O > > * A breadboard prototyping area > > > > The key thing here is that there's really no need to bother with a > programmer. > > That's traditional thinking. the 16F87X and 18FXXX (eventually) don't need > > traditional programmers on an ongoing basis. Once a bootloader has been > > installed into them, programming becomes as simple as plugging into a > serial > > port. > > I agree the bootloader would be a nice idea... The problem is programming > the chips in the first place (which is why I didn't suggest it). Sometimes my thinking is narrow because I generally operate in the small. It never really occured to me that someone would have to actually program a large number of chips. Even if we're operating on the order of 500 to 1000 units it still would take a significant amount of time to preprogram each with a bootloader. > > Ben Wirz and I have gone through some major headaches getting PIC16C505s and > PIC16C57s programmed for the "TAB Electronics Build Your Own Robot Kit". > Microchip will do it, if you have quantities over 10K and you can wait 10 > weeks (they will treat the parts as separate part number and you can repeat > order without having to resend the object files). The best vendor we've > found is Future-Active (Digi-Key was surprisingly bad). We've also worked > through a ton of small, crappy ones. So what's the scoop on Future-Active then? Lead time? cost? minimum quantity? > > What I have been toying around with is an RS-232 programmer circuit that can > also be used as an RS-232 interface. The problem is coming up with > something very simple that will work for LVP. A serial programmer is a tough game. You really need three usable outputs though you can get away with only one input. I guess that one output can be created using a zener and the others with the onboard MAX232. But honestly it really gets messy compared to simply having the chip preprogrammed on board. > > > What I'd really like to see is a combination of Wouter's Wloader and WISP > > in a single package.... Both are chip programmers. Wloader is a self > > [ The rest deleted for brevity - BAJ] > > Sounds good to me. Glad you like it. > > > I really like bootloaders. They cut the tether of a programmer. They are > > largely platform independant. They offer a really good independant > debugging > > channel. They are simple to clone. And they only cost as little as 1 I/O > pin > > (which can be user choosen) whereas ICSP will cost a minimum of 2, and > those > > are fixed. > > ?? Please explain. I would expect two lines (transmit and receive) for the > boot loader unless you will allow the PICmicro MCU to use a single line for > send and receive. This will work, but the software to control it is pretty > complex. The beauty of it is that it's already done. Wouter's Wloader operates exactly in this manner. The upshot of tying the XMIT and RECV together is that everything the PC outputs will be echoed. Actually this can be a good thing because the software gets automagic feedback when the programmer is properly connected. > > As for 2 lines for ICSP, please explain how this is done. I am looking at a > minimum of three (possible 4 for LVP unless a couple of single-shots are > used to sequence the PGM and _MCLR pins). Sorry Myke, I was unclear. Most of the time I only think of I/O as consumables with MCLR as a given. So you are correct: 3/4 pins for ICSP and 2 for a bootloader. And the designer still gets to pick the bootloader I/O pin. > > > Somehow the arguments have been presented that if a chip has a USART, > MSSP, > > PSP, multiple timers, A/D, and CCP that either a new user will be > overwhelmed > > by the complexity at the beginning, or that it's irrelevant because they > will > > never need those features. The latter is definitely untrue as some subset > of > > those periperals will be used in any non toy project. The former is easily > > mitigated because the tutorial doesn't have to present everything at once. > > I agree. A PIC16F87x can be used just as efficiently running initial > programs (ie flashing an LED) using PORTB as a PIC16F84. > > > > The best books are that ones that FIRST gives you something to > play, > > > and AFTER teaches you how does it works. If you see a LED flashing, > > > the first time of your life, you will be in a deer joy. After that, > > > you can learn how you can play it faster or slower, or else light up > > > at your control. > > > > I'd only like to add that any such manual should do two more things: > > > > * Extend into intermediate projects. > > * Show both the hardware and software only mechanisms for solving > problems. > > > > Think along the lines of the midrange manual with a real project > associated > > with each of the peripheral chapters. > > > > Note that these are in addition to all of the beginner projects. It can > > be separated into to major sections even. But they should both be there. > > > How many pages are you thinking of? In "Programming and Customizing > PICmicro(R) Microcontrollers", I do just that (although not in the order > that is being discussed). With the "Introduction to Programming" and > "Introduction to Electronics" sections printed out, this comes out to OVER > 1,500 pages. I think we were all thinking in terms of digital media as trying to publish paper will turn this from a project that can be done to one that's nearly impossible. Honestly I hadn't gotten to page counts yet. I'm still trying to get on the table the concept of offer material up to the early advanced stage, with a key on keeping it real simple early but adding reasonable and logical complexity as we progress. Then a newbie can stop at whatever comfort level makes them happy, with more material to utilize later. Organizationally we clearly are going to have to distribute the work. Frankly Myke, I can't see how you get it all done! > > With this project, I believe that it is _very_ important to keep it well > bounded. The programmer software, Bootloader code itself, sample projects, > explanatory text can involve literally person-years of effort even for a > fairly small project. Absolutely. And the more work that is enjoined the higher the likelyhood that it won't get finished. Ideally I'd hope to see existing projects polished and annotated. For example I simply published my thermostat on my web site as raw source. But there is the basis of several projects in there: * Driving multiplexed LED displays * Multiple conversions (DS1620->C->F->BCD->7segment) * Using a pot and A/D as a control input * Driving relays * syncronous serial interface (DS1620) * bitbanged async serial (via the bootloader interface) But organizing it isn't going to be much fun. > > Let's work at keeping it small at the start and then going bigger from > there... No problem with that. I'd still vote for the bootloader/ICSP programmer concept if we can figure out a reasonable way to either preprogram the chip or have the buyer EASILY!!! do the initial program. Software on the PC may be able to handle it if the initial programming interface and the bootloader interface were jumperable. BAJ [There's too much in one post. I'll tackle Myke's list later...] -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads