On Mon, Feb 06, 2006 at 08:47:09PM +0100, Tomas Larsson wrote: > > > > -----Original Message----- > > From: piclist-bounces@mit.edu > > [mailto:piclist-bounces@mit.edu] On Behalf Of Byron A Jeff > > Sent: Monday, February 06, 2006 7:59 PM > > To: Microcontroller discussion list - Public. > > Subject: Re: [PIC] Cheap programmer interface, was noob's 1st ques > > > > > > On Mon, Feb 06, 2006 at 06:11:45PM +0100, Tomas Larsson wrote: > > > You are forgetting one very important thing, todays PC (and > > > yesterdays PC as well) are simply not designed for this > > purpose, they > > > are designed to use peripheral equipment, such as programmer HW to > > > communicate on the lower level. > > > > I don't think that's true. USB was developed to give a single > > port with hot plug, hardware autodetect, and reasonable > > speed. This takes some complexity to accomplish. I get that. > > But its surge is going to wipe out other modes of interfacing. > > > > > There will never be a good way of controll serial ports, lpt or USB > > > ports, simply because they are not designed for that purpose. > > > > Serial and parallel port control interfaces have been defined > > for 20 years. One can take a 1985 DOS program and still > > wiggle the serial and parallel ports with it. It's a de facto > > standard... One unfortunately that is going extinct. > > > > > > > > > A PC based on x86 can't do realtime controll, why, because > > all IO is > > > DMA-based, it simply takes to much time to flush the cashe > > and reload > > > it. Therefore you are better of having some dedicated HW > > that does the > > > actual controll and timing. > > > > No argument there. > > > > > Once you have an working bootloader and a standard port (RS232, > > > USB....) on your target then you could use anything to > > communicate and > > > download what you want, but to get there you need some dedicated > > > HW-Tools. > > > > I disagree here. It's the crux of the discussion. With some > > compromises (USB to serial cable, 3 wire interface only) and > > some simple tools, it is possible to gain enough control to > > bootstrap the rest. No dedicated tools required. > > > > > I simply can't understand the problem, konnect the > > programmer, start > > > upp the SW download and verify your code, cant be simpler, and not > > > very expensive either. Me myself, I'm using the PicKey from > > FED, which > > > is a marvelous piece of equipment. > > > > A lot of hobby PIC development was fueled by the fact that > > one could build one's own development tools. Why should that > > ability disappear simply because the ports that supported it > > disappears? > > > > BAJ > > > > The ports are designed for one purpose only, to communicate, they are not > designed for timing purposes. Where exactly did timing come into this? BTW as async devices serial port's TX/RX have very precise timing. > The host cpu loads the serial or usb controller with data, the controller > handles the rest, the host cpu is never involved with the actual process > itself, it just do a DMA transfer to the peripheral controller with the > data, and of it goes. > > Real-time control involving the host CPU, involves to flush all cash memory > both data and instruction, and since today's cpus are heavily pipelined it > takes quit long time to do this, even on a 3000+ cpu. > The serial port is obsolete, we have to accept that, the same as ST506 and > ISA is obsolete, we have to take it from there and use dedicated HW to > perform these extra task we want I.E. program a PIC. > > The actual operating-system doesn't matter much since it is the > HW-architecture that puts the limits. It has to matter. A simple example. Take a look at the LIRC infra-red transmitter here: http://www.lirc.org/images/simple_transmitter.gif Trivial. Now the Linux LIRC driver wiggles that DTR pin precisely at 38 kHz. Now please explain how that can be when you state that the underlaying hardware architecture cannot support suck precise timing? BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist