> -----Original Message----- > From: piclist-bounces@mit.edu > [mailto:piclist-bounces@mit.edu] On Behalf Of Byron A Jeff > Sent: Monday, February 06, 2006 11:30 PM > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] Cheap programmer interface, was noob's 1st ques > > > 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? You need precise timing (at least sort of) if you are supposed to program a PIC. > > BTW as async devices serial port's TX/RX have very precise timing. Yes, handled by the usart which is programmed to a given baud-rate. Hence 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 I'm not saying that you can't do it, there is always ways to circumvent possible obstacles, what I'm saying is that the underlying hardware in a pc is not designed to do it, hence troubles to directly control hardware in a way it was not design to work. A serial port is designed to do one thing only, communicate to a given standard (RS232), i.e. send and receive a stream of data in a very well-defined way in a well-defined speed. The usart is programmed to do this with the baudrate, number of start and stop-bits and possibly a parity-bit. That's all, then some intelligent people found out, on the early 8086-80286 era that it might be possible to do more, at that era CPU's didn't use any cache, the CPU's were not that much pipelined, which means that these things were a fairly easy task to do, but with today's CPU's it is not that easy anymore. Still the support in HW isn't there, but you can circumvent, but I still don't understand why. Proper programmers are so cheap, and they work very well, are independent of the host. And most of all they don't cause any problems. With best regards Tomas Larsson Sweden http://www.naks.mine.nu for downloads etc. ftp://ktl.mine.nu for uploads. Or use the free www.yousendit.com service. Verus Amicus Est Tamquam Alter Idem -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist