From: "Byron A Jeff" > I think that educational is a misnomer here. From reading this message I'm > getting the impression that the sole purpose of the onboard I/O is to teach > concepts. It's not. As in my latest description, the package isn't solely educational, it does have features which are meant for educational purposes :) >The primary purposes are create a ready to use > development environment and to standardize the base so that everyone that > has one of these units can be assured of a base set of I/O devices when > developing or supporting a project. I don't see why my concept would obstruct the persuit of standardisation :) > Neither of these are primarily geared > towards the educational aspect. I think that the CD, documentation, and > tutorials that we plan to ship serve that purpose. It also don't have to be, I could easyly call my concept a development package with the ability to learn on prebuilt stuff :) > I think I finally have clarity on your dissent to I/O device integration, Your > PICbase fits well with the modular environment that you are describing where > you'll take the base and essentially permanently affix it to a project. So > for the next project, you'll start with a new base. Got it. And if that's the > tack then you are absolutely correct that the base should have as little > integration as possible. Tadaa heheh > Of course I'm tacking in a completely different direction... I knew it!! haha > > With putting alot of stuff on the same PCB as the PIC, you actually narrow > > its flexibility imo. > > With only the circuit to program, run & connect to a PIC on a PICbase, it > > can be used by everybody, for many many DIFFERENT things, this is about the > > widest flexibilty I can Imagine. Plus, you can work on different projects at > > the same time, just buy more PICbases. > Bingo! This is the crux of the difference between our paths. You're thinking > in terms of multiple small units, one per project. My Designer concept only > has a single reusable unit. It's used to develop the project, but it isn't > integrated into the project at the end. Instead the final project is > transferred off onto its own board and then the Designer is reused for the > next project. Correct, but my method doesn't exclude yours :) plug a PICbase into a breadboard, your designer or similar thing & you're already a fair bit on the way with your project. You can keep this 1 system for all your developments/experiments & still other users can use the other advantages. > True. But it still illustrates the point that without some additional item > for input, that the module cannot function in a completely standalone fashion. This is very much true, a soundmodule usually has no more then a simple monitoring function (1note) BUT, whatever the PBK is going to be, I don't think you are going to write & program it with the aid of only a pencil & a piece of paper. (i.o.w. I don't think you'll program many PICs without any kind of computer :) > > Another motivation could be that the keyboard versions are more expensive. > Absolutely. However if our musical friend didn't have a PC and still had to > make the same choice, it wouldn't be such a cut and dried decision. See above :) > > And, if later you still want a keyboard, you either could buy a cheap MIDI > > controllerkeyboard or a more expensive master keyboard to add to it. > Again I failed because of my poor formulation of my argument. If we have > both components and they can only be used in a standalone, not modular, > configuration, then there is a bit more contrast between the choices. I'm not sure if I understood you here, but the mentioned keyboards don't have sounds onboard, so they would be complementary. (ofcourse they could have, with more investment :) > Exactly. The problem is that developing for and supporting a modular system > is more difficult precisely because of the added complexity of modularity. I began my suggestion with a condition (if possible to be built ), I'm just trying to think of & describe how a max flexible system could look like in general terms, like I said before, it may be even practically impossible to build it. > If we have a system with 10 modular components and I develop a project with > modules 1,4 and 5 and you have modules 1,8, and 9, then for you to use, test, > or support my project, you'd have to purchase more modules. Yes naturally, but this over-modularising (you can take this to component level in all extremity), an edu board should be designed so it is complete on itself (incl PICbase then), for its intended purpose. If we were to build the same thing, let's say a HWsequencer, we both would buy a PICbase & you tell me (I'd hope heh ;) wat other stuff you are going to plug on (y)our development board (where we have plugged the PICbase in) & meanwhile some other kind soul is sharing another project with me, for which I have another PICbase & development board. :) > However if we both > shared a resuable base (my Designer, not your PICbase) that incorporated the > functionality of modules 1-6, We do share it :) I only gave examples of what could be on a board, the details are up to you,(I don't know which stuff is of equal level) its not that I have in mind stuff like 1 board with 6potmeters; 1 board with 3serial connectors; another board with with 13LEDs & a button etc etc.. I'm thinking of PICbase; Educational/experimenter boards ( number = ? mebbe its only 1, I can't tell) & development board(s.) + your (plural) ideas. > then I could be assured that anyone that had > a Designer could run my project out of the box. You still could :) > And I'm in full agreement with you that if every project physically > incorporated the Designer, that it wouldn't work. But the Designer is the > prototyping platform, not the final target, so the extra baggage of I/O > devices it carries won't carry over to the final project. With a PICbase in your designer I develop some project.When it works, I unplug it (or I just use another) & put it in its final box. This has saved me soldering together a bunch of general-not-directly-project-related-&-always-recurring circuitry.(& possible errors I could make in it) > > True, there will be a need to build different PCB's for the PBK, but on the > > other hand, alot more PICbases could be sold. > Since this isn't primarily a for profit venture, volumn sales isn't necessarily > a goal. However there is always the issue of mindshare. Well then, don't think about profit for the manufacturer, think about cost reduction for the enduser :) > > Your system would be re-useable if i'm not wrong., so you develop something > > & when its all working & testing, you're gonna build a new circuit to run > > your PIC & talk to your project. Your PBK then serves for another development. > Bingo. I think we both understand each other. Yes, I'm starting to get it too :) > > In my system, when some idea pops up, I buy a PICbase & I don't worry about > > a pwr > > supply or watever other gizmos it needs, nor do I waste time on soldering > > the same thing everytime. I just build the thing inside my project, basta :) > Right. But I think a cost analysis would need to be done as a comparison > of purchasing PICbases on a per project basis as opposed to prototyping on > a more expensive (initially) box then transferring the project to a real > cheap board. I bet a factory built PICbase is way cheaper & safer then buying the same components seperately in supersmall quantities as a hobbieist would do & If I were to let make a PCB for my project without the PICbase, the circuit would be also more complex. >The best example I can think of is the difference between using > Basic Stamps and raw PICs. The BS gives a quick to develop platform, however > there is a nearly $20 ongoing cost for each one. The PICs are cheaper but > require more external infrastructure to utilize. I'm not sure who the winner > would be in similar circumstances. see above. > So at the end of the day (or the end of post) we are in total agreement. > BTW if you need 10 bootloaded PICs, buy the 10 blanks and them program them > with a $5 programmer like my TLVP. Saves you both time and money. > You bootload into the Designer for development. You then use the Designer to > program the final target. The final target doesn't need to have a bootloader > on it unless you want to be able to field upgrade it. Understood. > > (e.g. 3weeks ago in a local store, I had to pay 20(twenty!!) friggin Euro > > for a silly plastic flatcable PCB connector) > > OUCH! INDEED! > ICSP - In Circuit Serial Programm[ing,er]. Instead of transferring the chip to > be programmed into the programmer, you connect a cable directly to the target > and you program the chip in circuit. Usually this means that the programmer > doesn't have to have a socket for the chip to be programmed to sit in. Ah, oki. > The answer is yes and yes. However it's only for common, resuable I/O. > Remember I agree it doesn't work in a modular scheme where you'd pay each time > you started a new project. In my modular system I dont buy 'more' then you, for every project you do, you will also buy a PIC, a crystal etc. (& solder it together) I buy the same thing, only as an assembled package, which saves me some work :) I have no coments on the proposed components, its beyond my knowledge to know what is necessary. :) Best regards -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.