On 2/5/06, Wouter van Ooijen <spam_OUTwouterTakeThisOuTvoti.nl> wrote:
>
> A big (literally) disadvantage of usb-parallel converters is that all
> versions I have seen have a cnetronics-male connector, which is bulky,
> and the corresponding female connector is not as easy to find as a DB9.
> A slight advantage is that usb-parallel conveters are somewhat cheaper
> than usb-serial converters.

Are USB-parallel converters common at all? To be honest, I have not
seen a physical one yet. USB-seral converter is much more common.

I will say to buy a usb-parallel to just build a cheap programmer is a
very strange idea. ;-)

> Are USB-parallel converters common at all? To be honest, I have not
> seen a physical one yet. USB-seral converter is much more common.

Both in the computer shops in town and at my main supplier they are as
common as a serial converter, and cheaper. Maybe because they don't need
a voltage converter. But the big centronics connector makes them clumsy.

>> Are USB-parallel converters common at all? To be honest, I have not
>> seen a physical one yet. USB-seral converter is much more common.
>
> Both in the computer shops in town and at my main supplier they are as
> common as a serial converter, and cheaper. Maybe because they don't need
> a voltage converter. But the big centronics connector makes them clumsy.

The cheapest hit on pricewatch.com has a db25 female connector; that's
better to use than the Centronics.

But it still costs $13 (and the warranty sounds kind of strange). If the
goal is to make a low-cost PIC programmer, a programmed PIC for a "real"
programmer is probably cheaper.

> On 2/5/06, Wouter van Ooijen <.....wouterKILLspam@spam@voti.nl> wrote:
>>
>> A big (literally) disadvantage of usb-parallel converters is that all
>> versions I have seen have a cnetronics-male connector, which is bulky,
>> and the corresponding female connector is not as easy to find as a DB9.
>> A slight advantage is that usb-parallel conveters are somewhat cheaper
>> than usb-serial converters.
>
> Are USB-parallel converters common at all? To be honest, I have not
> seen a physical one yet. USB-seral converter is much more common.

They are common enough ;-(

> I will say to buy a usb-parallel to just build a cheap programmer is a
> very strange idea. ;-)

On Sun, Feb 05, 2006 at 04:49:51PM +0800, Xiaofan Chen wrote:
> On 2/5/06, Wouter van Ooijen <wouterKILLspamvoti.nl> wrote:
> >
> > A big (literally) disadvantage of usb-parallel converters is that all
> > versions I have seen have a cnetronics-male connector, which is bulky,
> > and the corresponding female connector is not as easy to find as a DB9.
> > A slight advantage is that usb-parallel conveters are somewhat cheaper
> > than usb-serial converters.
>
> Are USB-parallel converters common at all? To be honest, I have not
> seen a physical one yet. USB-seral converter is much more common.

>
> I will say to buy a usb-parallel to just build a cheap programmer is a
> very strange idea. ;-)

The scope goes beyond that. With the impending death of parallel and serial
ports on PC hardware, there's no effective way for hackers to control
signals directly from their PC. Folks like James, Bob, and myself do not
necessarily think it's a good thing to be dependent on others to supply
extra hardware in order to have some measure of hardware control from a PC.

You yourself have seen the struggle to get prebuilt hardware to work with
Linux for example. If all hardware is out of your control, then you are
stuck with only with others supply.

USB to serial (and parallel) hardware is hardly unique. I'm pretty sure I
could drive out to the Walmart just this minute and find at least one
such adapter. With some simple hardware attached, some measure of control
can be reacquired.

Now truly the point is somewhat moot at this point. Parallel nor serial ports
haven't been buried yet. However, the need for them will dissapate as more
and more hardware becomes USB attached.

On Sun, Feb 05, 2006 at 09:26:43AM -0200, Gerhard Fiedler wrote:
> Wouter van Ooijen wrote:
>
> >> Are USB-parallel converters common at all? To be honest, I have not
> >> seen a physical one yet. USB-seral converter is much more common.
> >
> > Both in the computer shops in town and at my main supplier they are as
> > common as a serial converter, and cheaper. Maybe because they don't need
> > a voltage converter. But the big centronics connector makes them clumsy.
>
> The cheapest hit on pricewatch.com has a db25 female connector; that's
> better to use than the Centronics.
>
> But it still costs $13 (and the warranty sounds kind of strange). If the
> goal is to make a low-cost PIC programmer, a programmed PIC for a "real"
> programmer is probably cheaper.

I started this thread. Cheap isn't the sole goal. Part of it is to maintain
some measure of control of the hardware. If one cannot build any type of
device that can be directly controlled by the user, then that user is now
dependent for others to supply hardware for them.

PIC programmers are going that route. Early in the PIC game there were
tons of programmers (NoPPP, Tait, JDM, etc.) that one could put together
for oneself. With the bastardization of the serial port, and the impending
disappearace of the parallel port (already gone from most modern laptops)
such devices no longer work.

So the cables represent one of the few commodity links to allowing for
direct control of hardware on a PC.

> From: .....piclist-bouncesKILLspam.....mit.edu
> [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu] On Behalf Of Byron A Jeff
>
> > I will say to buy a usb-parallel to just build a cheap
> programmer is a very strange idea. ;-)
>
> The scope goes beyond that. With the impending death of
> parallel and serial ports on PC hardware, there's no effective
> way for hackers to control signals directly from their PC.
> Folks like James, Bob, and myself do not necessarily think
> it's a good thing to be dependent on others to supply
> extra hardware in order to have some measure of hardware
> control from a PC.

Okay I only thought about current PICs when I said that. If I
start to think about AVR/MPS430/LPC ARMs and even the future
PICs, USB-to-parallel converter might be useful to build
a simple JTAG programmer and debugger. The only thing I have
access to and use the parallel port interface now is an ICE2000
which has been lying there for sometimes.

Maybe I am just a bit biased against parallel port based
things because I once had a ZIP drive which suffered from
the infamous "click of death"...

> You yourself have seen the struggle to get prebuilt hardware
> to work with Linux for example. If all hardware is out of
> your control, then you are stuck with only with others supply.
>

Okay I can better understand you now. Maybe I am pretty weak
in programming (I am much better at messing with software)
so that I think we should leave the hard jobs to those people
who have the expertise and have spent their fare amount of
efforts on it ... I am still thinking in this line but I
can understand your motivation now.

> On Sun, Feb 05, 2006 at 04:49:51PM +0800, Xiaofan
> Chen wrote:
> > On 2/5/06, Wouter van Ooijen <@spam@wouterKILLspamvoti.nl>
> wrote:
> > >
> > > A big (literally) disadvantage of usb-parallel
> converters is that all
> > > versions I have seen have a cnetronics-male
> connector, which is bulky,
> > > and the corresponding female connector is not as
> easy to find as a DB9.
> > > A slight advantage is that usb-parallel
> conveters are somewhat cheaper
> > > than usb-serial converters.
> >
> > Are USB-parallel converters common at all? To be
> honest, I have not
> > seen a physical one yet. USB-seral converter is
> much more common.
>
> Ebay has a ton of them. Here's a sample:
>
>

>
> >
> > I will say to buy a usb-parallel to just build a
> cheap programmer is a
> > very strange idea. ;-)
>
> The scope goes beyond that. With the impending death
> of parallel and serial
> ports on PC hardware, there's no effective way for
> hackers to control
> signals directly from their PC. Folks like James,
> Bob, and myself do not
> necessarily think it's a good thing to be dependent
> on others to supply
> extra hardware in order to have some measure of
> hardware control from a PC.
>
> You yourself have seen the struggle to get prebuilt
> hardware to work with
> Linux for example. If all hardware is out of your
> control, then you are
> stuck with only with others supply.
>
> USB to serial (and parallel) hardware is hardly
> unique. I'm pretty sure I
> could drive out to the Walmart just this minute and
> find at least one
> such adapter. With some simple hardware attached,
> some measure of control
> can be reacquired.
>
> Now truly the point is somewhat moot at this point.
> Parallel nor serial ports
> haven't been buried yet. However, the need for them
> will dissapate as more
> and more hardware becomes USB attached.
>
> BAJ

>>>> Are USB-parallel converters common at all? To be honest, I have not
>>>> seen a physical one yet. USB-seral converter is much more common.

>>> Both in the computer shops in town and at my main supplier they are as
>>> common as a serial converter, and cheaper. [...]

>> But it still costs $13 (and the warranty sounds kind of strange). If the
>> goal is to make a low-cost PIC programmer, a programmed PIC for a "real"
>> programmer is probably cheaper.
>
> I started this thread. Cheap isn't the sole goal. Part of it is to maintain
> some measure of control of the hardware. [...]

> So the cables represent one of the few commodity links to allowing for
> direct control of hardware on a PC.

I still question the means... between

1- buying a commercial USB-to-Parallel converter to be able to wiggle some
pins in a limited way and building a limited programmer around it, and

2- buying a programmed PIC to do exactly that (wiggling some pins) in a
much less limited way (and then build the rest of the minimal hardware
around the PIC),

to me the second version looks more "in control", more "DIY".

In a way, to me this feels similar to trying to make a CD player look like
an old record player :)

> Serial port completely erased from the PC world? I personally hope not!
> When the day comes OUCH! Have to find out HOW to interface USB and the
> MCU together which makes it unnecessary complex.
>
> Anyway, I believe PC manufacturers do know that PC are being used in
> factory environments. A lot of factory interface uses RS-232.

Yes, but those few PCs can always use USB-to-serial adapters or PCI (or
whatever) cards. It doesn't make sense to add an interface that's only used
by a small fraction of the users to the standard equipment.

> I still question the means... between
>
> 1- buying a commercial USB-to-Parallel converter to be able
> to wiggle some
> pins in a limited way and building a limited programmer
> around it, and
>
> 2- buying a programmed PIC to do exactly that (wiggling some
> pins) in a
> much less limited way (and then build the rest of the minimal hardware
> around the PIC),
>
> to me the second version looks more "in control", more "DIY".

Byron A Jeff wrote:
> I started this thread. Cheap isn't the sole goal. Part of it is to
> maintain some measure of control of the hardware. If one cannot build
> any type of device that can be directly controlled by the user, then
> that user is now dependent for others to supply hardware for them.

I just don't get this. You buy a PC and are dependent on someone building
the motherboard, programming the bios, etc. You probably wouldn't consider
building your own soldering iron, and you don't think twice about being
dependent on the manufacturer to program the PIC inside to regulate the
temperature.

Think of a PIC programmer as any other tool. It connects to a PC on one
side and a PIC on the other. Why does it matter whether the part inbetween
uses only passive parts, a PIC, or relays to get the job done as long as it
works? Like most things, you might be able to build one yourself, but you
can also probably buy one that works cheaply enough. I don't see why the
PIC programmer is being singled out and treated differently that your other
tools, other than it seems you personally feel you know something about PICs
and therefore just don't like the idea of having someone else take care of
that part for you. That's certainly your call, but everyone is going to see
this tradeoff differently. What you are asking for is no different from
plans for a soldering iron that can be built without requiring a soldering
iron. Perhaps possible, but silly by many people's standards.

Yes. Virtually all new peripheral hardware has USB interfaces.
PCs will get to a point where all PS2, parallel and serial
interface will be eliminated, leaving only a ton of USB interfaces
to connect with. There's no point in having a parallel port
if printers do not have parallel ports. There is equally
no point in having serial ports if mice, modems, and
the like do not have serial interfaces. It becomes a waste
of space.

> I personally hope not! When the day comes OUCH! Have to
> find out HOW to interface USB and the MCU together
> which makes it unnecessary complex.

Now you see my motivation.

> Anyway, I believe PC manufacturers do know that PC are
> being used in factory environments. A lot of factory
> interface uses RS-232.

I think they will get to a point where they will convince
themselves and their customers that a USB to serial
converter is best used in such legacy situations.

Having anything other that USB will eventually become
cost prohibative. And if you think that it hasn't happened
before, try and find a modern motherboard with ISA slots on
it.

> Byron A Jeff wrote:
>
> >>>> Are USB-parallel converters common at all? To be honest, I have not
> >>>> seen a physical one yet. USB-seral converter is much more common.
>
> >>> Both in the computer shops in town and at my main supplier they are as
> >>> common as a serial converter, and cheaper. [...]
>
> >> But it still costs $13 (and the warranty sounds kind of strange). If the
> >> goal is to make a low-cost PIC programmer, a programmed PIC for a "real"
> >> programmer is probably cheaper.
> >
> > I started this thread. Cheap isn't the sole goal. Part of it is to maintain
> > some measure of control of the hardware. [...]
>
> > So the cables represent one of the few commodity links to allowing for
> > direct control of hardware on a PC.
>
> I still question the means... between
>
> 1- buying a commercial USB-to-Parallel converter to be able to wiggle some
> pins in a limited way and building a limited programmer around it, and

It's not just about programmers. Parallel and serial ports over the years
have been used to interface to a wide variety of hardware. Consider the
X10 Firecracker and LIRC interface hardware as examples.

> 2- buying a programmed PIC to do exactly that (wiggling some pins) in a
> much less limited way (and then build the rest of the minimal hardware
> around the PIC),
>
> to me the second version looks more "in control", more "DIY".

I would agree if all PICs came with bootloaders on them. However, when
you get samples from MChips, or purchase from Mouser, DigiKey, Jameco,
or even Randy from GlitchBusters, they come blank.

Remember that in my world view, programmers are not important. They only
function they serve in to install bootloaders into blank chips. So I
firmly believe in being able to perform that activity with commodity
components (emphesis on commodity).

Your second solution requires that you purchase from a specialized
vendor, such as Wouter or Olin for example.

On Mon, Feb 06, 2006 at 01:13:12PM +0100, Wouter van Ooijen wrote:
> > I still question the means... between
> >
> > 1- buying a commercial USB-to-Parallel converter to be able
> > to wiggle some
> > pins in a limited way and building a limited programmer
> > around it, and
> >
> > 2- buying a programmed PIC to do exactly that (wiggling some
> > pins) in a
> > much less limited way (and then build the rest of the minimal hardware
> > around the PIC),
> >
> > to me the second version looks more "in control", more "DIY".
>
> But much less 'available around the corner'.

Bingo! There's no way it would pass the Sunday afternoon Radio Shack
(spares etc) test.

On Mon, Feb 06, 2006 at 08:05:56AM -0500, Olin Lathrop wrote:
> Byron A Jeff wrote:
> > I started this thread. Cheap isn't the sole goal. Part of it is to
> > maintain some measure of control of the hardware. If one cannot build
> > any type of device that can be directly controlled by the user, then
> > that user is now dependent for others to supply hardware for them.
>
> I just don't get this. You buy a PC and are dependent on someone building
> the motherboard, programming the bios, etc.

All are commodity components. You can get them from literally thousands
of vendors in a variety of ways and cost options.

> You probably wouldn't consider
> building your own soldering iron, and you don't think twice about being
> dependent on the manufacturer to program the PIC inside to regulate the
> temperature.

While a PIC is single source, it too is virtually a commodity component
because it too is obtainable from a long list of sources.

>
> Think of a PIC programmer as any other tool. It connects to a PC on one
> side and a PIC on the other. Why does it matter whether the part inbetween
> uses only passive parts, a PIC, or relays to get the job done as long as it
> works?

It has always been personal with me on this subject Olin. PIC programmers
are not real important in my world view. As such they need to be cheap and
commodity. You simply cannot pick one up off the shelf. My Trivial programmer
has always been doable with commodity components available from lots of
vendors including the local Radio Shack until very recently. So factors
such as quick to build and commodity components are important to me.

> Like most things, you might be able to build one yourself, but you
> can also probably buy one that works cheaply enough.

Not off the shelf. And each of the other items that you listed above are
easily purchased off the shelf.

> I don't see why the
> PIC programmer is being singled out and treated differently that your other
> tools,

It's not a commodity item and it's not important in my development cycle.

> other than it seems you personally feel you know something about PICs
> and therefore just don't like the idea of having someone else take care of
> that part for you. That's certainly your call, but everyone is going to see
> this tradeoff differently.

I agree. That's one reason why I explain my view on it. It's certainly not
for everyone. However, just because it's a niche position doesn't mean that
it's a position that should be vacated. And with the gradual elimination
of parallel and serial ports towards USB, it's a position that would have
to be vacated.

> What you are asking for is no different from
> plans for a soldering iron that can be built without requiring a soldering
> iron. Perhaps possible, but silly by many people's standards.

> > other than it seems you personally feel you know something about PICs
> > and therefore just don't like the idea of having someone else take care of
> > that part for you. That's certainly your call, but everyone is going to see
> > this tradeoff differently.

The DIY aspects of PIC development is one of the reasons why it has such
a large hobby following. Free development software and cheap and easy to
build programming hardware fueled hobby PIC development. While cost
effective options such as PicKit 2, EasyProg, and WISP628 are available,
my Trivial Programmer Forums tell me that there's still a roll your
own crowd out there whose needs may be unmet in the impending conversion
to USB.

It's not just a better investment, it's an absolutely neccessary one. If
you do any tech at all, you need a serial port.

I've done PIC development three different ways:

1. True hardware emulator

2. ICD/ICD2

3. Serial bootloader

#1 and #2 suffer from power cycling issues. Unless your circuit draws very
little current, you end up haveing to mouseclick and flip switch in just
the right order or everything hangs.

#1 is very expensive.

#1 is very noisy if you are doing analog stuff.

#2 uses pins you really want to use for other things.

#2 gives you very little in the way of debugging.

#1 and #2 are most useful when you can single step. Not useful at all in a
realtime circuit, especially one that can self-destruct if stopped at the
wrong time.

#3 uses just one cable, no extra power, is fast, and you can debug through
it. Sure you have to include a serial output routine in your code to do
it, but it doesn't take much to set up the usart and output a byte where
you'd put a breakpoint.

So in the future, you'll have a serial port or it'll be on your list
anyway. Getting a bootloader into the PIC is the important thing. Byron's
circuit with 555's is a step in the right direction. You can still get
them at Radio Shack! And the circuit could also be built with schmitt
triggers or oneshots if you prefer.

>Byron A Jeff wrote:
>
>
>
>>BTW I think that USB to serial is a better investment.
>>
>>
>
>It's not just a better investment, it's an absolutely neccessary one. If
>you do any tech at all, you need a serial port.
>
>I've done PIC development three different ways:
>
>1. True hardware emulator
>
>2. ICD/ICD2
>
>3. Serial bootloader
>
>#1 and #2 suffer from power cycling issues. Unless your circuit draws very
>little current, you end up haveing to mouseclick and flip switch in just
>the right order or everything hangs.
>
>#1 is very expensive.
>
>#1 is very noisy if you are doing analog stuff.
>
>#2 uses pins you really want to use for other things.
>
>#2 gives you very little in the way of debugging.
>
>#1 and #2 are most useful when you can single step. Not useful at all in a
>realtime circuit, especially one that can self-destruct if stopped at the
>wrong time.
>
>#3 uses just one cable, no extra power, is fast, and you can debug through
>it. Sure you have to include a serial output routine in your code to do
>it, but it doesn't take much to set up the usart and output a byte where
>you'd put a breakpoint.
>
>So in the future, you'll have a serial port or it'll be on your list
>anyway. Getting a bootloader into the PIC is the important thing. Byron's
>circuit with 555's is a step in the right direction. You can still get
>them at Radio Shack! And the circuit could also be built with schmitt
>triggers or oneshots if you prefer.
>
>Cheerful regards,
>
>Bob
>
>
>
>

Well said, Bob

er... Bob, did you know there is a "Bob" convention in Iowa every year?
Ya gotta be named Bob,
a Robert just won't do....

On Mon, Feb 06, 2006 at 11:18:04AM -0500, Byron A Jeff wrote:
> > But much less 'available around the corner'.
>
> Bingo! There's no way it would pass the Sunday afternoon Radio Shack
> (spares etc) test.

Speakin of... I heard that Radio Shack is expanding their electronics
sections in their stores. Anyone else heard of that?

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. There will never be a good way of controll serial ports, lpt or USB
ports, simply because they are not designed for that purpose.

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.
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 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.

On Mon, Feb 06, 2006 at 12:23:53PM -0500, Peter Todd wrote:
> On Mon, Feb 06, 2006 at 11:18:04AM -0500, Byron A Jeff wrote:
> > > But much less 'available around the corner'.
> >
> > Bingo! There's no way it would pass the Sunday afternoon Radio Shack
> > (spares etc) test.
>
> Speakin of... I heard that Radio Shack is expanding their electronics
> sections in their stores. Anyone else heard of that?

It's hit or miss. Generally the mall stores are devoid of electronics.
Others have varying sizes of cabinets with electronics stuff. The
smallest have resistors, caps, switches, and relays. The largest carry
diodes, ICs, LEDs, and the like.

On Mon, Feb 06, 2006 at 08:44:02AM -0800, Bob Blick wrote:
> Byron A Jeff wrote:
>
> > BTW I think that USB to serial is a better investment.
>
> It's not just a better investment, it's an absolutely neccessary one. If
> you do any tech at all, you need a serial port.

> I've done PIC development three different ways:
>
> 1. True hardware emulator
>
> 2. ICD/ICD2
>
> 3. Serial bootloader
>
> #1 and #2 suffer from power cycling issues. Unless your circuit draws very
> little current, you end up haveing to mouseclick and flip switch in just
> the right order or everything hangs.
>
> #1 is very expensive.
>
> #1 is very noisy if you are doing analog stuff.
>
> #2 uses pins you really want to use for other things.

This is one of the primary reasons I like bootloaders.

> #2 gives you very little in the way of debugging.

Can you expand upon that? It would seem that hardware breakpoints
would be the ultimate in debugging capability.

> #1 and #2 are most useful when you can single step. Not useful at all in a
> realtime circuit, especially one that can self-destruct if stopped at the
> wrong time.
>
> #3 uses just one cable, no extra power, is fast, and you can debug through
> it. Sure you have to include a serial output routine in your code to do
> it, but it doesn't take much to set up the usart and output a byte where
> you'd put a breakpoint.

usart? I have bit bang serial routines for output. Usually I use Timer2 because
of it's autoreload feature.

> So in the future, you'll have a serial port or it'll be on your list
> anyway. Getting a bootloader into the PIC is the important thing. Byron's
> circuit with 555's is a step in the right direction. You can still get
> them at Radio Shack! And the circuit could also be built with schmitt
> triggers or oneshots if you prefer.

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?

>> Byron A Jeff wrote:
>> #2 gives you very little in the way of debugging.
>
> Can you expand upon that? It would seem that hardware breakpoints
> would be the ultimate in debugging capability.

The ICD/ICD2 give you a hardware breakpoint, but it's an "always" break.
If you want "break on data" you need a compare and branch, so it's not
transparent like a full featured emulator would be.

> usart? I have bit bang serial routines for output. Usually I use Timer2
> because
> of it's autoreload feature.

Absolutely, any way that's convenient. I have a debugging monitor that I
can drop in to a project, with both usart and bit-bashed versions, and
also with or without using interrupts. The least intrusive to your code
and its timing would be to use the usart, and just drop a byte to it when
you need to.

You have the right idea with your programmer, I wish I had time to offer
some help.

> -----Original Message-----
> From: spamBeGonepiclist-bouncesspamBeGonemit.edu
> [TakeThisOuTpiclist-bouncesEraseMEspam_OUTmit.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.

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.

part 1 1487 bytes content-type:TEXT/PLAIN; charset=US-ASCII; format=flowed
I agree with all the arguments. One must know how to build leaf switches
out of old coffee cans and resistors out of lead pencils. This is not,
to prove how macho one is, since the girlfriend wouldn't understand
anyway. This is really something that self sufficient men need to do,
together with buying all kinds of tools and storing them in several
sheds, and watching 'house improvement'.

Laughs aside (we will pick them up again soon), I designed & built all
my pic programmers so far (since ~1995), and I do all my own development
on them. Every time I saw someone buy a super duper do-them-all-50,000
chips programmer so far, I also saw the person discover that one of the
few chips they wanted to program with it had buggy support, followed by
interesting waiting time for the software update (is the email in yet -
repeated every five minutes for as long as it takes).

To help out people who really want to feel independent, and who still
have some room left in the toolshed, I attach an untried but very likely
functional manual pic programmer, that does not require any operating
systems, and even works without coffee. The algorythm can be edited with
any pencil and the timing is very flexible. It uses the latest wetware
everyone owns already, and requires only a soldering iron and a few
parts anyone can obtain. It represents a great advance compared to the
pic programmer based on two morse keys operated simultaneously behind
one's back.

> Having anything other that USB will eventually become
> cost prohibative. And if you think that it hasn't happened
> before, try and find a modern motherboard with ISA slots on
> it.

Speaking of deja vu, weren't Macs somewhat crippled in the sense that
they renounced serial and parallel in favor of USB (and non-standard
serial) a long time ago ? And weren't Mac users paying premium for
common interfacing products like mice and keyboards at the time ?

>
>
> > -----Original Message-----
> > From: RemoveMEpiclist-bouncesTakeThisOuTmit.edu
> > [piclist-bouncesEraseME.....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.

> 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:

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?

>
> > 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:
>
> 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.

I've used #1 and #2. I think #1 does help a lot. And I am using
the ICD2 to help my design now. I can not use #3 since the chip
I used does not support bootloader function. Take note all the
"standard flash" PICs does not support bootloader. This may
or may not be a limitation for the hobbyists though.

> #1 and #2 suffer from power cycling issues. Unless your
> circuit draws very little current, you end up haveing to
> mouseclick and flip switch in just the right order or
> everything hangs.
>
> #1 is very expensive.

Agreed.

> #1 is very noisy if you are doing analog stuff.

True. Still the emulator/debugger will mainly help you
with the firmware development, not the analog stuff.
For that you need a good oscilloscope!

> #2 uses pins you really want to use for other things.

#3 also uses pins you want to use as well.

> #2 gives you very little in the way of debugging.

I think ICD2 is good enough for quite some development.
And there are simulators as well to help out.

> #1 and #2 are most useful when you can single step. Not
> useful at all in a realtime circuit, especially one that
> can self-destruct if stopped at the wrong time.

You do not hook your ICE/ICD2 to that. You can simulate the output
using relays/LEDs/Beepers/...

> #3 uses just one cable, no extra power, is fast, and you can
> debug through it. Sure you have to include a serial output
> routine in your code to do it, but it doesn't take much to
> set up the usart and output a byte where you'd put a breakpoint.

As much as I see your points, I think your give the impression
that #3 is better than #1 and #2. I think that is wrong. If
one can afford an ICE2000/ICE4000 and the processor modules,
by all means go and get it. It will help a lot. An ICD2 is
one of the best investment for PIC development at its money.

Serial based monitor/debugger is good in some cases. However,
an ICD2 and an ICE will be a very useful tool to speed up the
debugging process.

This is similar to software debugging. Yes, "printf"s
(similar to the serial monitor) will help the debugging.
But a good debugger will also help. People use debug/gdb/...
(similar to ICE/ICD) to help troubleshooting as well.

> So in the future, you'll have a serial port or it'll be on your list
> anyway. Getting a bootloader into the PIC is the important
> thing. Byron's circuit with 555's is a step in the right direction.
> You can still get them at Radio Shack! And the circuit could also
> be built with schmitt triggers or oneshots if you prefer.
>

Even though I agree to have a bootloader in certain cases is
good, I do not think it is such an important thing and is
not necessary in many cases. For newbies, it complicates the
developing and debugging process.

On Tue, Feb 07, 2006 at 12:11:30AM +0100, Tomas Larsson wrote:
> > > 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.

Sort of is correct. The timing requirements are minimal. 1 uS between
commands and some very tiny clock width that is trivially met by
virtually any PC serial/parallel interface.

As one of the other posters showed, a pic can be programmed by hand if
necessary.

To use others arguments myself: what difference does it make which part
of the system causes the precise timing? The PC truly is a black box with
edge interfaces. The only problem I see is that those edge interfaces are
fast turning USB only. The USB/serial cable I continue to propose as
an interface wedge turns the edge back into a RS232 edge.

> > [more snippage]
> > > 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 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:
> >
> > 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.

I give pause to the contradiction of "not designed to do it" with the fact
that for 20 years it did exactly that. PC serial and parallel interfaces
were so defacto a standard as to be virtually dejure.

I agree with you that the times are changing. I disagree that simply
admitting defeat because of the interface change.

>
> A serial port is designed to do one thing only, communicate to a given
> standard (RS232),

EIA-232C technically. And the PC serial port is a bastardization of that
standard.

> 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.

But by your argument, the USART is a black box of the serial port. The
fact of the matter is that up until now that simply hasn't been true.

> 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.

It has nothing to do with cache or pipelining. All I'm saying is that simple
hardware can still be used to capture the resulting output stream, which
is unchanged.

> 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.

"Proper programmers" have single source, cost, support,and software issues.
Each leads to some set of issues for the DIY hacker.

Olin Lathrop Sent: 2006 Feb 06, Mon 11:07
> Byron A Jeff wrote:
> > A lot of hobby PIC development was fueled by the fact that
> one could
> > build one's own development tools.
>
> Then they all come here asking why they can't get their LED to blink.

And we happily answer those questions and help the best we can. Isn't that
right?

> The ports are designed for one purpose only, to communicate,
> they are not designed for timing purposes.

Could you check the USART / Serial data standards on that one? I'm pretty
sure they are designed for accurate timing. When you set 9600N81 you get a
very specific frequency of pulses from the port. +/- a few percent at worst.

And even parallel ports have maximum and minimum timing requirement. And you
can control the rate of data delivery via the handshaking lines.

A simple circuit that makes use of those timings to program a PIC is of
value.

>> 1. True hardware emulator
>> 2. ICD/ICD2
>> 3. Serial bootloader
>
> I've used #1 and #2. I think #1 does help a lot. And I am using
> the ICD2 to help my design now. I can not use #3 since the chip
> I used does not support bootloader function. Take note all the
> "standard flash" PICs does not support bootloader. This may
> or may not be a limitation for the hobbyists though.
>
> #3 also uses pins you want to use as well.

Not if you use the usart as a usart.

> As much as I see your points, I think your give the impression
> that #3 is better than #1 and #2. I think that is wrong. If
> one can afford an ICE2000/ICE4000 and the processor modules,
> by all means go and get it. It will help a lot. An ICD2 is
> one of the best investment for PIC development at its money.

I have an ICE and it sits on the shelf. I hate it. I have an ICD and an
ICD2. Same thing.

> Even though I agree to have a bootloader in certain cases is
> good, I do not think it is such an important thing and is
> not necessary in many cases. For newbies, it complicates the
> developing and debugging process.

But since you have not used a bootloader, you have not had the chance to
see how useful it can be, even when one already has an ICD or ICE.

If Microchip made a faster and more reliable ICD that might change my
opinion somewhat. But once I started using a bootloader, my productivity
went up.

> I agree with all the arguments. One must know how to build
> leaf switches out of old coffee cans and resistors out of
> lead pencils. This is not, to prove how macho one is, since
> the girlfriend wouldn't understand anyway. This is really
> something that self sufficient men need to do, together with
> buying all kinds of tools and storing them in several sheds,
> and watching 'house improvement'.

Yep, that's me. It isn't real until I understand it top to bottom and can
watch it work.

> Laughs aside (we will pick them up again soon), I designed &
> built all my pic programmers so far (since ~1995), and I do
> all my own development on them. Every time I saw someone buy
> a super duper do-them-all-50,000 chips programmer so far, I
> also saw the person discover that one of the few chips they
> wanted to program with it had buggy support, followed by
> interesting waiting time for the software update (is the
> email in yet - repeated every five minutes for as long as it takes).

Been there, had that done to me. Now, I should say that I've purchased all
my programmers, but I studied the programming protocol and understood it
well for each chip. When I've had a problem with a programmer, I can email
them exactly where it is messing up. If they had been open source (non have
been so far) I could have fixed it myself.

The other side of it is that I'm totally addicted to in circuit debugging
and the details of that interface are not usually available. For the SX's,
we (the SX community) has figured it out long ago, but I guess the ICD
protocol for the PIC is still closed? In any case, I only mention ICD's
because I know I'm going to buy the company made hardware anyway. My
interest in this thread is purely educational.

> To help out people who really want to feel independent, and
> who still have some room left in the toolshed, I attach an
> untried but very likely functional manual pic programmer,

Most funny! Thanks for sharing. But really, a circuit like that hooked up to
a serial port with the clock derived from a one-shot...

Actually I have used bootloader (tiny bootloader and the USB
bootloader) even though I have not used it at work. I am now
collecting more information about PIC bootloader. I can
see that bootloader and serial monitor can be very useful.
In fact I will start my dsPIC experiment and one of the first
thing I want to try is a dsPIC bootloader (I've already
tried one from Daniel Chia). My point of view is still that
all three debugging methods have their pros and cons. I can
see why #3 is more preferred by hobbyists. But if one can
afford to buy an ICD2, that is a good investment. It is a
capable programmer as well as a capable debugger even though
it has its limitations. It will be even useful for PIC18
and dsPIC development.

Our ICE2000 is on the shelf as well. One of the reason is that
we do not want to buy the processor modules and our program
can be debugged effectively with the ICD2 and a good
oscilloscope.

> If Microchip made a faster and more reliable ICD that might
> change my opinion somewhat. But once I started using a bootloader,
> my productivity went up.
>

I think this is a valid criticism to ICD/ICD2. I wish they
could improve the ICD2. Maybe an ICD3 will be better. In fact,
I think there will be alternative debuggers for the new JTAG
equipped PIC24 and dsPIC33. However they are not that suitable
to hobbyists yet due to the lack of DIP packages.

Really? On advantage of bootloaders is that you get to choose the
interface. You get to pick the pin(s) for the interface. For example
Wouter's WLoader defaulted to PortE2 on a 16F877. It's much more out
of the way than the RB6/RB7 combo demanded by the ICD interface.

[more snippage]

> As much as I see your points, I think your give the impression
> that #3 is better than #1 and #2. I think that is wrong.

I have to agree. OTOH #3 is certainly a viable way to do PIC
development also. And with it being a viable way to do PIC development
then the issues raised in this thread have validity.

> If
> one can afford an ICE2000/ICE4000 and the processor modules,
> by all means go and get it. It will help a lot. An ICD2 is
> one of the best investment for PIC development at its money.
>
> Serial based monitor/debugger is good in some cases. However,
> an ICD2 and an ICE will be a very useful tool to speed up the
> debugging process.
>
> This is similar to software debugging. Yes, "printf"s
> (similar to the serial monitor) will help the debugging.
> But a good debugger will also help. People use debug/gdb/...
> (similar to ICE/ICD) to help troubleshooting as well.

All are viable choices. However the slow passage of interface
ports to USB make #3 a less viable option. I'm just considering
ways to keep it alive as an option.

> > So in the future, you'll have a serial port or it'll be on your list
> > anyway. Getting a bootloader into the PIC is the important
> > thing. Byron's circuit with 555's is a step in the right direction.
> > You can still get them at Radio Shack! And the circuit could also
> > be built with schmitt triggers or oneshots if you prefer.
> >
>
> Even though I agree to have a bootloader in certain cases is
> good, I do not think it is such an important thing and is
> not necessary in many cases.

It's a choice. Some of us find the development model useful.

> For newbies, it complicates the developing and debugging process.

How so? Any code movement issues are trivially linked out. As Bob
has pointed out debugging can be enhanced by the phantom serial
interface that can be utilized by the application in real time.

On Mon, Feb 06, 2006 at 05:05:21PM -0800, Bob Blick wrote:
> If Microchip made a faster and more reliable ICD that might change my
> opinion somewhat. But once I started using a bootloader, my productivity
> went up.

As did mine. All of my real PIC projects, and not just the toys, were
done with a bootloader. While it's just two data points, they do lend
validity to the concept.

On Tue, Feb 07, 2006 at 09:57:00AM +0800, Chen Xiao Fan wrote:
>
>
> > -----Original Message-----
> > From: spamBeGonepiclist-bouncesKILLspammit.edu
> > [.....piclist-bouncesspam_OUTmit.edu] On Behalf Of Bob Blick
> >
> > But since you have not used a bootloader, you have not had
> > the chance to see how useful it can be, even when one already
> > has an ICD or ICE.
>
> Actually I have used bootloader (tiny bootloader and the USB
> bootloader) even though I have not used it at work.

Cool.

> I am now
> collecting more information about PIC bootloader. I can
> see that bootloader and serial monitor can be very useful.
> In fact I will start my dsPIC experiment and one of the first
> thing I want to try is a dsPIC bootloader (I've already
> tried one from Daniel Chia). My point of view is still that
> all three debugging methods have their pros and cons.

Definitely. One of the major problems with a bootloader is that
you need some bootstrap hardware just to get the bootloader in the
chip in the first place.

> I can see why #3 is more preferred by hobbyists.

I don't think it is. I think that many hobbyists go the very
traditional route of building/buying a parallel/serial programmer
and then use that programmer directly in the development cycle.

> But if one can
> afford to buy an ICD2, that is a good investment. It is a
> capable programmer as well as a capable debugger even though
> it has its limitations. It will be even useful for PIC18
> and dsPIC development.

But it leads to the catch-22: Why spend the money on a programmer
that is rarely used in the actual development cycle?

>> So in the future, you'll have a serial port or it'll be on your list
>> anyway. Getting a bootloader into the PIC is the important thing.

So if actual USB PIC programmers reach the price of USB-Serial
converters ($20-$40, right?) and are readily available from
reputable mail order vendors without exorbitant shipping and
handling charges, do you still really need a more DIY-style
interface to the PC? I mean, USB->serial converters don't have
the popularity and economies of scale you'd expect. Fact is, the
average computer user doesn't have anything serial to connect TO,
either, and despite the attraction to SOME, many would-be-pic-users
don't want to have to fiddle much with their PC to program PICs.
And we're already there, right? USB "Baseline flash programmer": $25.
I can buy a USB-Serial cable for less than that, but not around the
corner at radioshack (Model: 26-183, Catalog #: 26-183 $39.95)
Once you can program any of the baseline chips, THEY can be programmed
to put bootloader code into everything else.

(Hmm. There's another idea. Tiny PIC and big serial flash, pre-loaded
with bootstrap code for "all known" PICs. Connect it up to your
bare chip and get a bootloader-based chip instead... Dispense with
the need for "communications" as part of the bootstrap process.)

> You need precise timing (at least sort of) if you are supposed
> to program a PIC.

It's important to remember that "sort of" part.

>> 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.

IO instructions to control external bits are quite slow. The
pipeline gets stalled, all the out-of-order execution stuff has
to come to a halt, and other stuff slows. I don't THINK that
caches are flushed; cache coherency is handled separately and
the IO space and memory space are separate. But an IO instruction
to set a UART register takes literally hundreds to thousands of
cycles on a machine that normally executes somewhat more than one
instruction in each cycle, so it's incredibly inefficient.

However, that's still ~1000 cycles at 3GHz, which is still
significantly less than a microsecond, which is plenty small
a time interval for programming PICs. (But you'll not that
it's not much faster than a PIC can twiddle pins... :-)
And no one really cares how inefficient a computer is these
days, as longs as it's fast...

Of more serious concern is that sometime during that 50uS pulse
you wanted, something like a legacy USB bios or power management
interrupt will come along and do something (or nothing) for 30uS
or so and screw up everything...

>Every time I saw someone buy a super duper
>do-them-all-50,000 chips programmer so far, I also saw
>the person discover that one of the few chips they
>wanted to program with it had buggy support, followed
>by interesting waiting time for the software update
>(is the email in yet - repeated every five minutes for
>as long as it takes).

I am always amazed (or maybe I shouldn't be) at the short lifetime of these
"do-all-chips" devices, as the developers find that they just cannot upgrade
the software to keep up with the changing programming strategies. I had
access to just such a device at one time, and had occasion to program a
number of chips, and ended up with about a 30% programming failure.

Investigation with a 'scope showed that the programming pulse timings were
nothing like the data sheet for the chip. It appeared that the chip maker
had a process change between the chips that (may) have been used to verify
the design, and now the timings were much more critical. I ended up building
a little tagboard programmer with some one shots that produced the correct
timings, and satisfactorily programmed the chips that had failed.

Bob Blick wrote:
> But since you have not used a bootloader, you have not had the chance to
> see how useful it can be, even when one already has an ICD or ICE.

I have used everything you mentioned (ICE, ICD2, bootloader) plus direct
load via ICSP, and replace chip in socket that you didn't mention.

Of all these methods, the ICE is definitely the best for debugging. You can
see everything going on in the chip in the real target circuit environment
without requiring additional resources, which can often be a serious
limitation. The downside is that an ICE is relatively expensive for
hobbyists (it's a no-brainer for professionals where time=money and you get
the heft discount) and lately there have been more and more limitations as
the chips get faster. Still, this is currently my debug method of choice
for most projects simply because it's the fastest way to get to working
code.

The ICD2 is a good value for the money, but I use it only grudgingly because
there seem to be some flakies and it has some annoying properties even when
it's working right. Still, it's probably the best value for a serious
hobbyist.

Most modern PIC circuits are designed for ICSP. For those it's easy to dump
a new version into the PIC and try it. I usually set up a build script that
automatically dumps the HEX file to the PIC via a programmer if the build
succeeded. As long as your circuit is set up for ICSP, this is better than
a bootloader in all cases since it requires no extra hardware resources, and
takes about the same time or less. The only drawback from a hobbyist point
of view is that you need a programmer, preferably one capable of releasing
the programming lines to high impedence when done depending on how the
circuit is wired and the PGC/PGD pins used. I think a minimum programmer is
a must for a hobbyist anyway, and that relying solely or mostly on a
bootloader is not a good idea. I use a ProProg for this since the EasyProg
was not designed to release the lines when done. The new USB programmer is
designed for that (working very nicely from a serial port by the way, faster
than the EasyProg and ProProg, USB software/firmware in progress).

I have used a bootloader a few times, generally when that was required for
the finished project anyway. In that case it's about equivalent to an ICSP
dump since the hardware is designed for bootloader access. In one case the
circuit wasn't designed for ICSP but the project required a bootloader for
field upgrades, so I used that. However it's been a few years since the
last time I saw a circuit not designed for ICSP. The drawbacks of a
bootloader are that there are too many things that can go wrong, it requires
hardware resources, and you still have to get the bootloader in the chip the
first time plus whenever you mess up and overwrite it. Also many chips are
not capable of bootloading or a bootloader would take too large a fraction
of the limited program memory. My 16F UART based bootloader is around 300
words if I remember right, and my dsPIC external IIC EEPROM bootloader is
about the same number of instructions. Both were carefully designed for
reliability, so it should be possible to make smaller quick and dirty
bootloaders. However, I think that is a bad idea since there are already
enough risks and hassles when using bootloaders.

In the end, I usually use a combination of initial test with the simulator,
then real debugging with the ICE, then testing incremental changes using
ICSP dump-and-run. Once the firmware is basically working, bugs are minimal
and when they do occur you can usually find them from the symptom fairly
quickly. At that stage I only haul out the ICE when I'm really stumped and
can't figure it out with a few minutes of testing.

> Most funny! Thanks for sharing. But really, a circuit like that hooked up to
> a serial port with the clock derived from a one-shot...

How about two phototransistors suction cupped to the monitor screen and
a Javascript program to flash two rectangles in the right seuqence ?
Galvanic insulation for free. Works with a Mac! Heck, it even works with
a TV and a VCR ;-)

On Tue, Feb 07, 2006 at 11:17:31PM +0200, Peter wrote:
>
> On Mon, 6 Feb 2006, James Newtons Massmind wrote:
>
> > Most funny! Thanks for sharing. But really, a circuit like that hooked up to
> > a serial port with the clock derived from a one-shot...
>
> How about two phototransistors suction cupped to the monitor screen and
> a Javascript program to flash two rectangles in the right seuqence ?
> Galvanic insulation for free. Works with a Mac! Heck, it even works with
> a TV and a VCR ;-)

We can start supplying computer programs on video tape! It's the logical
extension of when you used to hook up your casette player to your
computer...

> How about two phototransistors suction cupped to the monitor screen and
> a Javascript program to flash two rectangles in the right seuqence ?
> Galvanic insulation for free. Works with a Mac! Heck, it even works with
> a TV and a VCR ;-)

Now this is an innovative idea... "Honey, have you seen my tape with the
bootloader?" :)

> -----Original Message-----
> From: TakeThisOuTpiclist-bouncesKILLspamspammit.edu
> [.....piclist-bouncesRemoveMEmit.edu] On Behalf Of Alan B. Pearce
>
> I am always amazed (or maybe I shouldn't be) at the short
> lifetime of these "do-all-chips" devices, as the developers
> find that they just cannot upgrade the software to keep up
> with the changing programming strategies. I had
> access to just such a device at one time, and had occasion to
> program a number of chips, and ended up with about a 30%
> programming failure.
>
There are good ones for production usage. They are normally
very expensive and not so suitable for small companies,
let alone hobbyists.

In the production we use Data I/O gang programmers. Each
adapter costs several hundred dollars and there are
also software maintenance fees.

We had an old Sprint (bought over by Data I/O) single programmer
in my department. When I started to use PIC, I thought of use that
programmer but the software update fee was more than the cost of
Promate II plus a few adapters. The adapter is also expensive.
So I bought the Promate II instead.

> In the end, I usually use a combination of initial test with the simulator,

For what do you guys use the simulator? The only time I used it was when I
tried to get familiar with the PIC architecture. That's a while ago now.
Since then, I never looked back at it... it doesn't seem to be able to do
me any good. As a consequence, of course, I'm not at all familiar with it,
and may miss out on something :)

For me, it works like this: I do simulate, but only hardware; unusual
constructs or when I'm not sure where the limits are. For the PIC itself,
the simple framework that sets up all the basic functions usually is done
quickly. (C, and past projects help here.) Never before used peripherals I
often get to work by thoroughly reading the manual, or they don't work well
with the simulator anyway (like the CAN bus interface) and may need some
real-world experimenting. After that, almost all the problems that pop up
have to do with interactions with the process environment, which is usually
not easy to simulate with MPLAB. Something like Proteus may help here, but
by the time you have successfully simulated your circuit and the process
environment, you probably have developed the product without the simulation
:) (And note that I'm a fan of process simulation. I even studied it in
university. It's a lot of fun, but it's also a lot of work :)

So I kind of never found the right place for MPLAB-style firmware
simulation. Where is it?

One thing that just came to my mind is test and optimization of special bit
wiggling routines that work in the microseconds and have critical timing.
That's probably something the simulator does quite well -- it's just
something I don't do that often.

> > Most funny! Thanks for sharing. But really, a circuit like
> that hooked
> > up to a serial port with the clock derived from a one-shot...
>
> How about two phototransistors suction cupped to the monitor
> screen and a Javascript program to flash two rectangles in
> the right seuqence ?
> Galvanic insulation for free. Works with a Mac! Heck, it even
> works with a TV and a VCR ;-)
>

I love it! I'll host the programming software on the web site and now we
have total port independence.

Remember when Byte Magazine was printing software in barcode? Same thing,
but with a pair of phototransistors focused on the paper. Now you can fax
your updates to the remote office.

There should be a contest: "Most unusual interface to program a PIC that
actually works."

James Newton, Host wrote:
>>How about two phototransistors suction cupped to the monitor
>>screen and a Javascript program to flash two rectangles in
>>the right seuqence ?
>
> There should be a contest: "Most unusual interface to program a PIC that
> actually works."

Hey, how about printing dark spots on transparencies, then feeding them
past the phototransistors with a light behind. (Some guy actually did
this for a player marimba - story in the last issue of MAKE.) The
advantage is that you wouldn't need a computer once you'd printed out
your master.

Or you could do the same thing, but punch holes in opaque paper. Now
where have I seen that idea before...
--
Timothy J. Weberhttp://timothyweber.org

>> But really, a circuit like that hooked up to
>> a serial port with the clock derived from a one-shot...
>
> How about two phototransistors suction cupped to the monitor
> screen and a program to flash two rectangles in the right seuqence ?

I had a remarkably similar thought myself, although I was going
to use CDS photocells... We're all sick.

Maybe we should just do it? It probably takes at least 3 signals,
doesn't it?

On Tue, Feb 07, 2006 at 04:23:34PM -0800, James Newton, Host wrote:
> I love it! I'll host the programming software on the web site and now we
> have total port independence.
>
> Remember when Byte Magazine was printing software in barcode? Same thing,
> but with a pair of phototransistors focused on the paper. Now you can fax
> your updates to the remote office.
>
> There should be a contest: "Most unusual interface to program a PIC that
> actually works."

I dunno about you, but the first image that popped into my mind, was a
drum kit...

> On Feb 7, 2006, at 1:17 PM, Peter wrote:
>
> >> But really, a circuit like that hooked up to
> >> a serial port with the clock derived from a one-shot...
> >
> > How about two phototransistors suction cupped to the monitor
> > screen and a program to flash two rectangles in the right seuqence ?
>
> I had a remarkably similar thought myself, although I was going
> to use CDS photocells... We're all sick.

I think CdS cells would be too slow - you really need semiconductor detectors to make it feasible.

> Maybe we should just do it? It probably takes at least 3 signals,
> doesn't it?

Two should be enough: Clock and Data. The device would need to train itself to the light and dark levels each
time it was used, but that shouldn't be difficult.

Timex made a watch a number of years ago that used this technique, so that you could maintain a diary (and
perhaps address book?) on the PC and transfer your appointments to the watch so it could act as an alarm clock
for anything you had booked. Quite clever, but you'd use Bluetooth nowadays for the same thing, and it tends
to be phones rather than watches.

>>> How about two phototransistors suction cupped to the monitor
>>> screen and a program to flash two rectangles in the right seuqence ?
>>
>> I had a remarkably similar thought myself, although I was going
>> to use CDS photocells... We're all sick.
>
> I think CdS cells would be too slow - you really need semiconductor
> detectors to make it feasible.

Hmm. I was thinking slower might be better. We don't want separate
signals at 30khz (horiz scan freq?) on every scan line "near" the
sensor, after all (although that might be easier to filter...)

> Timex made a watch a number of years ago that used this technique

I picked up some of these "PDAs"at christmas, that seem to use
a similar technique:

> Peter wrote:
>
>> How about two phototransistors suction cupped to the monitor screen and
>> a Javascript program to flash two rectangles in the right seuqence ?
>> Galvanic insulation for free. Works with a Mac! Heck, it even works with
>> a TV and a VCR ;-)
>
> Now this is an innovative idea... "Honey, have you seen my tape with the
> bootloader?" :)

Oh dear, ... I think I taped the 147688th episode of the 'ugly and the
immortal' onto it last friday.

> On Feb 7, 2006, at 1:17 PM, Peter wrote:
>
>>> But really, a circuit like that hooked up to
>>> a serial port with the clock derived from a one-shot...
>>
>> How about two phototransistors suction cupped to the monitor
>> screen and a program to flash two rectangles in the right seuqence ?
>
> I had a remarkably similar thought myself, although I was going
> to use CDS photocells... We're all sick.
>
> Maybe we should just do it? It probably takes at least 3 signals,
> doesn't it?

2 are enough as you need a power/run/program switch anyway, and that can
handle the power/vpp sequencing. Please read my other posting about
flicker and low pass.

On the other hand, making a contraption using perforated (on 2 tracks)
video tape (removed from cassette) and a hand crank should work fine.
The tape has two tracks, one for clock, one for data, and the data holes
must be smaller (or registered later than the relevant clock edge).

> On Tue, Feb 07, 2006 at 04:23:34PM -0800, James Newton, Host wrote:
>> I love it! I'll host the programming software on the web site and now we
>> have total port independence.
>>
>> Remember when Byte Magazine was printing software in barcode? Same thing,
>> but with a pair of phototransistors focused on the paper. Now you can fax
>> your updates to the remote office.
>>
>> There should be a contest: "Most unusual interface to program a PIC that
>> actually works."
>
> I dunno about you, but the first image that popped into my mind, was a
> drum kit...

> On the other hand, making a contraption using perforated (on 2 tracks)
> video tape (removed from cassette) and a hand crank should work fine.
> The tape has two tracks, one for clock, one for data, and the data holes
> must be smaller (or registered later than the relevant clock edge).

>> We can start supplying computer programs on video tape! It's the logical
>> extension of when you used to hook up your casette player to your
>> computer...

> but how can you verify that th data is correct??? You still need a
> pic-to-pc interface...

You can use the original two signals to read out from the chip, and use
another one that provides the data that should come out. The circuit then
compares the two, and if there is a difference, it triggers an LED through
a flip-flop that can only be reset manually. You just try again then...

Might need an enable signal for the comparison, but in principle it should
work.

>> On the other hand, making a contraption using perforated (on 2 tracks)
>> video tape (removed from cassette) and a hand crank should work fine.
>> The tape has two tracks, one for clock, one for data, and the data holes
>> must be smaller (or registered later than the relevant clock edge).
>
>
> I'm thinking "Music Box"...

When I was young (still am) we used ASR Teletypes to create the papertape,
that we later could mount in the tapereader on the actual computer itself
(Alpha LSI16).
Maybe that would be an approach.
Wonder what the market would look like for producing the TTY's again?

On 2/9/06, Tomas Larsson <tomaslarssonseEraseMEyahoo.se> wrote:
>
> When I was young (still am) we used ASR Teletypes to create the papertape,
> that we later could mount in the tapereader on the actual computer itself
> (Alpha LSI16).
> Maybe that would be an approach.
> Wonder what the market would look like for producing the TTY's again?

> When I was young (still am) we used ASR Teletypes to create the papertape,
> that we later could mount in the tapereader on the actual computer itself
> (Alpha LSI16).
> Maybe that would be an approach.
> Wonder what the market would look like for producing the TTY's again?

You would have Chinese clones for $50 a piece on the market before the
first batch sold out.

>It would have to be 9-track to fix the registration
>problem. It is easier to implement a self-clocked one
>track protocol. That's why 9-tracks are dead.

Are you referring to 9 track 800/1600BPI tape? If so then the 1600BPI NRZI
tapes were certainly self clocking on each track, and could deal with quite
reasonable skew between tracks without errors because of this.

>> It would have to be 9-track to fix the registration
>> problem. It is easier to implement a self-clocked one
>> track protocol. That's why 9-tracks are dead.
>
> Are you referring to 9 track 800/1600BPI tape? If so then the 1600BPI NRZI
> tapes were certainly self clocking on each track, and could deal with quite
> reasonable skew between tracks without errors because of this.
>
> Alan (who used to repair 1600BPI controllers).

I was referring to soemthing like 5-track + clock (registration?) paper
tape.

You are not far off from the reality btw :) There was quite popular
VCR based backup system ARVID in Russia awhile ago ( last one I've
heard was Arvid-1052 release ) Dig the google or altavista if curious.

WBR Dmitry.

Peter Todd wrote:
>
> On Tue, Feb 07, 2006 at 11:17:31PM +0200, Peter wrote:
>
> We can start supplying computer programs on video tape! It's the logical
> extension of when you used to hook up your casette player to your
> computer...

I know this is a very old thread, but technically the 18F4550 and family
DO have a maximum time parameter: P17, MCLR fall to VDD fall, max 100ns.
See DS39622.

Actually, I wanted to add one other (potentially more serious, but also
maybe weirder) comment: our primary complaint is that we only have USB
ports to work with. Well, ignoring the other complaint about
platform-specific software, how about this: doesn't the USB
specification require that a particular USB port can have its power
switched on or off under software control? Why not use the USB +5V
supply line as a twiddle pin? It would need a kernel-mode driver, sure,
but it could work (unless I'm quite mistaken about that part of the
specification - I thought you had to enable power to only one port at a
time in order to give a device an address before bringing another
unconfigured device onto the bus).

Chris

Olin Lathrop wrote:

> Tomas Larsson wrote:
>> You need precise timing (at least sort of) if you are supposed to
>> program a PIC.
>
> No, you don't. You only need to guarantee minimum timing. If you know of a
> contrary case, please point out the specific passage in a programming spec.

> but technically the 18F4550 and family
> DO have a maximum time parameter: P17, MCLR fall to VDD fall, max 100ns.
> See DS39622.
interesting given that at least one of microchips own programmers (the ICD2) can't follow that (since it doesn't control VDD) and yet programs the chip fine i'd take it with a pinch of salt.

maybe that figure is for if you have MCLR disabled, an oscilator availible during programming (either intosc or programming in cuircuit) and you don't wan't the pic to start running in the programming setup.

>
> Actually, I wanted to add one other (potentially more serious, but also
> maybe weirder) comment: our primary complaint is that we only have USB
> ports to work with. Well, ignoring the other complaint about
> platform-specific software, how about this: doesn't the USB
> specification require that a particular USB port can have its power
> switched on or off under software control? Why not use the USB +5V
> supply line as a twiddle pin? It would need a kernel-mode driver, sure,
> but it could work (unless I'm quite mistaken about that part of the
> specification - I thought you had to enable power to only one port at a
> time in order to give a device an address before bringing another
> unconfigured device onto the bus).

don't think so, despite the name USB IS NOT A BUS it is a tree of point to point links and the ports always seem to stay powered (except when you short them out ;) ).

and even if it does turn out that usb ports are supposed to be able to have thier power switched from software i'd be willing to bet that it would be even more of a compatibility nightmare than handshake lines on serial ports.

now for some more comments related to this thread (in no particular order).

One thing i've wondered for a while, is it possible to program a bootloader using LVP and then use self programming to disable LVP? the specs say you can't use LVP to disable LVP but they say nothing about if you can use self programming to do it. Has anyone tried this?

also for building an intelligent programmer losing an IO pin is hardly critical

afaict USB-whatever (serial parallell GPIO etc) converters will always have the problem for bit banging that USB is fairly high latency, the only real way arround this is to have something programmable at the device end of the usb link (e.g. a pic18f2550) and code the bit banging there

one thing i think would be helpfull is a site selling pics programmed to order so those of us who design pic based projects but don't want to get into online sales ourselved could just upload our hexfiles to it and put up "buy your pre-programmed pic here" link. Its not nice for a newbie to find that they have to build a crappy serial programmer or buy a fairly pricy programmer before they can start on building a decent programmer (or building some other pic based project they found on the net).

I dissagree about the idea that someone starting with pics and going down the build your own road is unlikely to have some collection of parts already. I'd think that someone with no electronics knowlage would be far more likely to buy a ready designed demo board. I'm sure there are plenty of people with a fair level of electronics experiance but who have never used pics before.

BTW to the piclist.com webadmin, it seems that just reading through a long thread page by page in a normal web browser triggers your bot detection code every few posts.

peter green wrote:
[snip]
> don't think so, despite the name USB IS NOT A BUS it is a tree of point to point links and the ports always seem to stay powered (except when you short them out ;) ).

I'm not sure about that. I was under the impression that a hub, when
brought online, was required to power up one port at a time, since the
newly-powered device gets the unconfigured address and must be
configured before another device can be brought up. Again: I'm not sure.
I have the USB specifications, but I haven't read them yet. This is just
my impression.

>
> and even if it does turn out that usb ports are supposed to be able to have thier power switched from software i'd be willing to bet that it would be even more of a compatibility nightmare than handshake lines on serial ports.

But since the ports are real hardware, they must act (at least at the
hardware level) properly. I can see using some kind of Linux LiveCD with
the sole purpose of booting a custom kernel with the weird USB driver
and burning a pre-written hex file to a chip.

>
> now for some more comments related to this thread (in no particular order).
>
> One thing i've wondered for a while, is it possible to program a bootloader using LVP and then use self programming to disable LVP? the specs say you can't use LVP to disable LVP but they say nothing about if you can use self programming to do it. Has anyone tried this?

It sounds insanely dangerous. I can't see anywhere in the datasheet
which says it's impossible, but you have to erase a full block at a
time, and erasing the configuration registers blows away your USB
voltage regular, oscillator configuration, WDT, BOR, and all sorts of
other quite important things. If you're only trying to WRITE (i.e. only
change a 1 to a 0), it might be more doable in theory.

[snip]

> I dissagree about the idea that someone starting with pics and going down the build your own road is unlikely to have some collection of parts already. I'd think that someone with no electronics knowlage would be far more likely to buy a ready designed demo board. I'm sure there are plenty of people with a fair level of electronics experiance but who have never used pics before.

I fully agree with this. A little while ago, that was my exact
situation: I had done some electronics, but never seen a PIC before. I
wanted to get into PICs, but I didn't really see any way to get in other
than building my own programmer. I don't think my local electronics
shops even carry programmers. Today, I'd have no problem ordering a
programmer from Wouter or Olin, but back when I was first getting into
PICs, their names didn't mean anything to me - so I wasn't exactly going
to send them money. The point is, a soldering iron is something I can go
to a shop and look at before buying - I'm guaranteed to receive what I
pay for. I can't get a programmer at a local shop.

On 2/3/06, Alan B. Pearce <RemoveMEA.B.PearceEraseMEspam_OUTrl.ac.uk> wrote:
> >I'm not sure I get this yet... What's wrong with
> >using the modem pins of a serial port? Or is this
> >what you are thinking of using?
>
> That is exactly what he is wishing to do, but part of the discussion has
> revolved around how timings are unreliable when using USB-Serial interfaces.
>
> Personally I suspect the most reliable way to do it would be a USB-Printer
> port set up as a basic text only printer, and then fed repeated characters
> with one bit of the ASCII character being the clock, and one bit the serial
> data. Still does not give the feedback path, and would probably need three
> characters to clock one bit into the chip. Also if you streamed the data out
> the port, the chip may FIFO buffer it, and stream it into the chip too fast
> for it to write to the Flash.

Alan, what makes you think the USB/parallel is working different than
USB/serial conversion ? The frames for sending a command word from USB
to the USB transciever takes the same (too long) time.
You have no timing control between ASCII caracters sent.

Christopher Head wrote:
> Actually, I wanted to add one other (potentially more serious, but also
> maybe weirder) comment: our primary complaint is that we only have USB
> ports to work with.

I don't see why that is a complaint. USB is a lot more complicated for
device designers, but it is really easy for end users.

> doesn't the USB
> specification require that a particular USB port can have its power
> switched on or off under software control?

No.

> Why not use the USB +5V supply line as a twiddle pin?

The USB spec describes how much current the device is allowed to draw, and
what voltage and current the host is obligated to provide under various
circumstances. The host is never required to limit current. A host could
connect the USB power directly to the output of a 5V 200A electroplating
supply and be compliant.

But even if you could, creating another piece of hardware that uses a port
in a non-standard way is a bad idea. Look at all the frustration crappy PIC
programmers that cut corners have caused. We see posts here and on the
Microchip forums often about problems with el-cheapo programmers that try to
use the parallel or serial port voltages directly.

$35 for a PicKit2 is a good deal even for budget minded hobbyists. They cut
some corners to make it cheap, but it does work most of the time. My
USBProg (http://www.embedinc.com/products/eusb2) is only $80. It "just
works" by not cutting corners and keeping the voltages and timing within
spec. $80 is a good deal for professional applications. So why do you want
to create your own programmer that does something sleazy with the USB? At
best you're a hobbyist and you save $30 in return for a lot development and
debugging time and frustration. If you're a professional and can spend your
time doing billable work, $80 if far cheaper than even a sleazy programmer
you could design, build, and debug on your own.

> It would need a kernel-mode driver,

To save $30!!? (even if it did work that way).

> I thought you had to enable power to only one port at a
> time in order to give a device an address before bringing another
> unconfigured device onto the bus.

No, it doesn't work that way. If you're going to discuss USB at this level,
you really should read the spec first.

> -----Original Message-----
> From: EraseMEpiclist-bounces@spam@mit.edu [@spam@piclist-bouncesspam_OUT.....mit.edu]On Behalf
> Of Vasile Surducan
> Sent: 18 January 2007 06:26
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Cheap programmer interface, was noob's 1st ques
>
>
> On 2/3/06, Alan B. Pearce <spamBeGoneA.B.PearceEraseMErl.ac.uk> wrote:
> > >I'm not sure I get this yet... What's wrong with
> > >using the modem pins of a serial port? Or is this
> > >what you are thinking of using?
> >
> > That is exactly what he is wishing to do, but part of the discussion has
> > revolved around how timings are unreliable when using
> USB-Serial interfaces.
> >
> > Personally I suspect the most reliable way to do it would be a
> USB-Printer
> > port set up as a basic text only printer, and then fed repeated
> characters
> > with one bit of the ASCII character being the clock, and one
> bit the serial
> > data. Still does not give the feedback path, and would probably
> need three
> > characters to clock one bit into the chip. Also if you streamed
> the data out
> > the port, the chip may FIFO buffer it, and stream it into the
> chip too fast
> > for it to write to the Flash.
>
> Alan, what makes you think the USB/parallel is working different than
> USB/serial conversion ? The frames for sending a command word from USB
> to the USB transciever takes the same (too long) time.
> You have no timing control between ASCII caracters sent.

no but you do have the ability to send dummy characters that produce no transitions with this system.

you'd also have to deal with the handshake lines on the port (iirc paralell handshakes every character but i'm not sure what handshake mechanism it uses), you may be able to add some delay here fairly easilly too (say a resistor, a capacitor and a schmitt trigger).

> > don't think so, despite the name USB IS NOT A BUS it is a
> tree of point to point links and the ports always seem to
> stay powered (except when you short them out ;) ).
>
> I'm not sure about that. I was under the impression that a hub, when
> brought online, was required to power up one port at a time, since the
> newly-powered device gets the unconfigured address and must be
> configured before another device can be brought up. Again:
> I'm not sure.
> I have the USB specifications, but I haven't read them yet.
> This is just
> my impression.
>

I believe that the power switching is handled by the device, and not the
upstream hub/port. When enumerated, devices are required to keep their
power consumption below some threshhold, and they will then communicate
their power needs and wait for the host to calculate a total power budget
before "approving" a higher load. In other words, higher power devices
must get permission from the host before drawing more than a minimal
current amount. They do their own power switching for their own loads.

There are a few different query/reply methods for the host to inquire
about power needs. Windows does not use them all. Some poorly written
USB devices ignore requests that are not used by windows. While writing
USB drivers for a new OS, I have seen some brands fail to enumerate after
current managment software was added to the USB stack.

Regarding a hub doing the switching.. the two ports on the front of my
Antec Sonata case have their +5Volt and Gnd contacts wired in parallel,
so switching of individual ports at that level is not possible.

I am not an expert. I welcome any corrections to my understanding of
how these things work. All facts are subject to verification. I reserve
the right to be wrong, and to learn from my mistakes.

>
>
> > -----Original Message-----
> > From: RemoveMEpiclist-bounces@spam@spamBeGonemit.edu [.....piclist-bounces@spam@EraseMEmit.edu]On Behalf
> > Of Vasile Surducan
> > Sent: 18 January 2007 06:26
> > To: Microcontroller discussion list - Public.
> > Subject: Re: [PIC] Cheap programmer interface, was noob's 1st ques
> >
> >
> > On 2/3/06, Alan B. Pearce <.....A.B.PearceRemoveMErl.ac.uk> wrote:
> > > >I'm not sure I get this yet... What's wrong with
> > > >using the modem pins of a serial port? Or is this
> > > >what you are thinking of using?
> > >
> > > That is exactly what he is wishing to do, but part of the discussion has
> > > revolved around how timings are unreliable when using
> > USB-Serial interfaces.
> > >
> > > Personally I suspect the most reliable way to do it would be a
> > USB-Printer
> > > port set up as a basic text only printer, and then fed repeated
> > characters
> > > with one bit of the ASCII character being the clock, and one
> > bit the serial
> > > data. Still does not give the feedback path, and would probably
> > need three
> > > characters to clock one bit into the chip. Also if you streamed
> > the data out
> > > the port, the chip may FIFO buffer it, and stream it into the
> > chip too fast
> > > for it to write to the Flash.
> >
> > Alan, what makes you think the USB/parallel is working different than
> > USB/serial conversion ? The frames for sending a command word from USB
> > to the USB transciever takes the same (too long) time.
> > You have no timing control between ASCII caracters sent.
> no but you do have the ability to send dummy characters that produce no transitions with this system.
>
> you'd also have to deal with the handshake lines on the port (iirc paralell handshakes every character but i'm not sure what handshake mechanism it uses), you may be able to add some delay here fairly easilly too (say a resistor, a capacitor and a schmitt trigger).

You didn't understand me. There is no difference in handshake
mechanism allowed by the USB transciever for serial or parallel jobs
as long the problem is the USB protocol itself.
Please read here:http://www.beyondlogic.org/usbnutshell/usb6.htm

You are both correct, of course :) The hub does not switch the power
pin. I was confusing this with the fact that the hub must be able to
issue a single-ended zero to a particular port in order to bring up
devices one at a time and assign addresses - because downstream packets
are transmitted to all (enabled) ports simultaneously, you need to bring
up devices one at a time to assign addresses. This seems significantly
less likely to be useful as a hack-communication device, especially
since the reset state appears to require SE0 for 10ms, rather than for a
host-defined period of time. Oh well...

> I believe that the power switching is handled by the device, and not the
> upstream hub/port. When enumerated, devices are required to keep their
> power consumption below some threshhold, and they will then communicate
> their power needs and wait for the host to calculate a total power budget
> before "approving" a higher load. In other words, higher power devices
> must get permission from the host before drawing more than a minimal
> current amount. They do their own power switching for their own loads.
>
> There are a few different query/reply methods for the host to inquire
> about power needs. Windows does not use them all. Some poorly written
> USB devices ignore requests that are not used by windows. While writing
> USB drivers for a new OS, I have seen some brands fail to enumerate after
> current managment software was added to the USB stack.
>
> Regarding a hub doing the switching.. the two ports on the front of my
> Antec Sonata case have their +5Volt and Gnd contacts wired in parallel,
> so switching of individual ports at that level is not possible.
>
> I am not an expert. I welcome any corrections to my understanding of
> how these things work. All facts are subject to verification. I reserve
> the right to be wrong, and to learn from my mistakes.
>
> Lyle
>