Searching \ for '[PIC] Cheap programmer interface, was noob's 1st q' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programmer
Search entire site for: 'Cheap programmer interface, was noob's 1st q'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Cheap programmer interface, was noob's 1st q'
2006\02\05@034951 by Xiaofan Chen

face picon face
On 2/5/06, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.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. ;-)

Regards,
Xiaofan

2006\02\05@044858 by Wouter van Ooijen

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

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\05@062704 by Gerhard Fiedler

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

Gerhard

2006\02\05@133134 by Peter

picon face

On Sun, 5 Feb 2006, Xiaofan Chen wrote:

> On 2/5/06, Wouter van Ooijen <.....wouterKILLspamspam@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. ;-)

In the 21st century ? You have a retrograde way of thinking ;-)

Peter

2006\02\05@203315 by Byron A Jeff

face picon face
On Sun, Feb 05, 2006 at 04:49:51PM +0800, Xiaofan Chen wrote:
> On 2/5/06, Wouter van Ooijen <wouterspamKILLspamvoti.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:

http://cgi.ebay.com/Dynex-6-Foot-USB-to-Parallel-Printer-Cable_W0QQitemZ6844731084QQcategoryZ51286QQrdZ1QQcmdZViewItem

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

2006\02\05@204107 by Byron A Jeff

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

BAJ

2006\02\05@210535 by Chen Xiao Fan

face
flavicon
face

> From: .....piclist-bouncesKILLspamspam.....mit.edu
> [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.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.

Regards,
Xiaofan

2006\02\05@214029 by kravnus wolf

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

John

--- Byron A Jeff <byronspamspam_OUTcc.gatech.edu> wrote:

{Quote hidden}

cgi.ebay.com/Dynex-6-Foot-USB-to-Parallel-Printer-Cable_W0QQitemZ6844731084QQcategoryZ51286QQrdZ1QQcmdZViewItem
{Quote hidden}

> --

2006\02\06@060346 by Gerhard Fiedler

picon face
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

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

Gerhard

2006\02\06@061106 by Gerhard Fiedler

picon face
kravnus wolf wrote:

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

Gerhard

2006\02\06@071112 by Wouter van Ooijen

face picon face
> 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'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\06@080451 by olin piclist

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


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\06@110814 by Byron A Jeff

face picon face
On Sun, Feb 05, 2006 at 06:40:28PM -0800, kravnus wolf wrote:
> Serial port completely erased from the PC world?

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.

BAJ

2006\02\06@111553 by Byron A Jeff

face picon face
On Mon, Feb 06, 2006 at 09:03:15AM -0200, Gerhard Fiedler wrote:
{Quote hidden}

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.

BTW I think that USB to serial is a better investment.

BAJ

2006\02\06@111805 by Byron A Jeff

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

BAJ

2006\02\06@112740 by Byron A Jeff

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

True. Actually it's one of the reasons I use wire wrap! ;-)

BAJ

2006\02\06@114214 by Byron A Jeff

face picon face
On Mon, Feb 06, 2006 at 11:27:39AM -0500, Byron A Jeff wrote:

I forgot one point.

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

BAJ

2006\02\06@114403 by Bob Blick

face picon face
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


2006\02\06@115856 by Bob Axtell

face picon face
Bob Blick wrote:

{Quote hidden}

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

--Bob'

--
Note: To protect our network,
attachments must be sent to
KILLspamattachKILLspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\06@120852 by Peter Todd

picon face
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?

--
RemoveMEpeteTakeThisOuTspampetertodd.ca http://www.petertodd.ca

2006\02\06@121150 by Tomas Larsson

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

With best regards

Tomas Larsson
Sweden

Verus Amicus Est Tamquam Alter Idem

> {Original Message removed}

2006\02\06@134851 by Byron A Jeff

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

BAJ

2006\02\06@135240 by Byron A Jeff

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

Bob, you of course know you're preaching to the choir with me.

{Quote hidden}

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.

Glad to get some support in this matter.

Thanks,

BAJ

2006\02\06@135903 by Byron A Jeff

face picon face
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

2006\02\06@140614 by olin piclist

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

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\06@141920 by Bob Blick

face picon face
I also forgot to mention debugging method #4 - "burn and crash" :)

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

Cheerful regards,

Bob


2006\02\06@144714 by Tomas Larsson

flavicon
face


{Quote hidden}

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.


2006\02\06@153309 by Peter

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

Peter

part 2 9315 bytes content-type:APPLICATION/pdf; name=mpicp-0-a.pdf (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\02\06@153651 by Peter

picon face

On Mon, 6 Feb 2006, Byron A Jeff wrote:

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

Peter

2006\02\06@172935 by Byron A Jeff

face picon face
On Mon, Feb 06, 2006 at 08:47:09PM +0100, Tomas Larsson wrote:
{Quote hidden}

Where exactly did timing come into this?

BTW as async devices serial port's TX/RX have very precise timing.

{Quote hidden}

It has to matter. A simple example. Take a look at the LIRC infra-red
transmitter here:

http://www.lirc.org/images/simple_transmitter.gif

Trivial. Now the Linux LIRC driver wiggles that DTR pin precisely at
38 kHz. Now please explain how that can be when you state that the
underlaying hardware architecture cannot support suck precise timing?

BAJ

2006\02\06@181135 by Tomas Larsson

flavicon
face


{Quote hidden}

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

>
> BTW as async devices serial port's TX/RX have very precise timing.


Yes, handled by the usart which is programmed to a given baud-rate. Hence
precise timing.



{Quote hidden}

I'm not saying that you can't do it, there is always ways to circumvent
possible obstacles, what I'm saying is that the underlying hardware in a pc
is not designed to do it, hence troubles to directly control hardware in a
way it was not design to work.

A serial port is designed to do one thing only, communicate to a given
standard (RS232), i.e. send and receive a stream of data in a very
well-defined way in a well-defined speed.
The usart is programmed to do this with the baudrate, number of start and
stop-bits and possibly a parity-bit. That's all, then some intelligent
people found out, on the early 8086-80286 era that it might be possible to
do more, at that era CPU's didn't use any cache, the CPU's were not that
much pipelined, which means that these things were a fairly easy task to do,
but with today's CPU's it is not that easy anymore.
Still the support in HW isn't there, but you can circumvent, but I still
don't understand why.
Proper programmers are so cheap, and they work very well, are independent of
the host. And most of all they don't cause any problems.


With best regards

Tomas Larsson
Sweden
http://www.naks.mine.nu for downloads etc.
ftp://ktl.mine.nu for uploads. Or use the free http://www.yousendit.com service.

Verus Amicus Est Tamquam Alter Idem




2006\02\06@193609 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: EraseMEpiclist-bouncesspamspamspamBeGonemit.edu
> [RemoveMEpiclist-bouncesKILLspamspammit.edu] On Behalf Of Bob Blick
>
>> 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

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.

Regards,
Xiaofan



2006\02\06@194510 by Byron A Jeff

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

>
> >
> > BTW as async devices serial port's TX/RX have very precise timing.
>
> Yes, handled by the usart which is programmed to a given baud-rate. Hence
> precise timing.

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.

{Quote hidden}

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.

BAJ

2006\02\06@195811 by James Newton, Host

face picon face
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?

---
James Newton: PICList webmaster/Admin
jamesnewtonSTOPspamspamspam_OUTpiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2006\02\06@200317 by James Newtons Massmind

face picon face

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

---
James.


2006\02\06@200522 by Bob Blick

face picon face
Xiaofan writes:

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

Cheerful regards,

Bob

2006\02\06@201610 by James Newtons Massmind

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

---
James.


2006\02\06@205703 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu
> [KILLspampiclist-bouncesspamBeGonespammit.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. 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.

Regards,
Xiaofan

2006\02\06@213811 by Byron A Jeff

face picon face
On Tue, Feb 07, 2006 at 08:36:06AM +0800, Chen Xiao Fan wrote:
>
> > -----Original Message-----
> > From: EraseMEpiclist-bouncesspamEraseMEmit.edu
> > [@spam@piclist-bounces@spam@spamspam_OUTmit.edu] On Behalf Of Bob Blick
> >
> >
> > I've done PIC development three different ways:
> >
> > 3. Serial bootloader
>
> > #2 [ICD] uses pins you really want to use for other things.
>
> #3 also uses pins you want to use as well.

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.

{Quote hidden}

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.

{Quote hidden}

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.

It just another option. An option just as valid as the others.

BAJ

2006\02\06@213943 by Byron A Jeff

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

BAJ

2006\02\06@214821 by Byron A Jeff

face picon face
On Tue, Feb 07, 2006 at 09:57:00AM +0800, Chen Xiao Fan wrote:
>
>
> > -----Original Message-----
> > From: spamBeGonepiclist-bouncesspamKILLspammit.edu
> > [.....piclist-bouncesspam_OUTspammit.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?

BAJ

2006\02\07@022600 by William Chops Westfield
face picon face

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

BillW

2006\02\07@024743 by William Chops Westfield

face picon face

On Feb 6, 2006, at 3:11 PM, Tomas Larsson wrote:

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

BillW

2006\02\07@054255 by Alan B. Pearce

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

2006\02\07@072552 by olin piclist

face picon face
First, please TRIM YOUR POSTS.  This last one was really getting rediculous.


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.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\07@083401 by olin piclist

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


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\07@161734 by Peter

picon face

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 ;-)

Peter

2006\02\07@173518 by Peter Todd

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

--
TakeThisOuTpete.....spamTakeThisOuTpetertodd.ca http://www.petertodd.ca

2006\02\07@185135 by Gerhard Fiedler

picon face
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?"  :)

Gerhard

2006\02\07@190353 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: TakeThisOuTpiclist-bouncesKILLspamspamspammit.edu
> [.....piclist-bouncesspamRemoveMEmit.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.

Regards,
Xiaofan

2006\02\07@190449 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

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

Thanks,
Gerhard

2006\02\07@192335 by James Newton, Host

face picon face
> > 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: PICList webmaster/Admin
RemoveMEjamesnewtonspamspamBeGonepiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2006\02\07@203808 by Timothy Weber

face picon face
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. Weber
http://timothyweber.org

2006\02\07@223043 by Denny Esterline

picon face
Have we really _advanced_ to the point where we're discussing programming
PICs with punch cards!?!

Actually I like the phototransistor flash idea. Has anybody tried a LCD
monitor?

-Denny

2006\02\07@232455 by William Chops Westfield

face picon face
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?

BillW

2006\02\07@234251 by Peter Todd

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

--
spamBeGonepete@spam@spamspam_OUTpetertodd.ca http://www.petertodd.ca

2006\02\08@034429 by Wouter van Ooijen

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

and we can have sublimal virusses! (read "snow crash")

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\02\08@064424 by Howard Winter

face
flavicon
picon face
Bill,

On Tue, 7 Feb 2006 20:24:53 -0800, William "Chops" Westfield wrote:

{Quote hidden}

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.

Cheers,


Howard Winter
St.Albans, England


2006\02\08@113104 by William Chops Westfield

face picon face

On Feb 8, 2006, at 3:44 AM, Howard Winter wrote:

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

http://www.geeks.com/details.asp?invtid=AQU-ZTOUCH&cat=PDA

BillW

2006\02\08@134553 by Juan Cubillo

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

Juan Cubillo

{Original Message removed}

2006\02\08@142416 by Peter

picon face


On Tue, 7 Feb 2006, Gerhard Fiedler wrote:

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

Peter

2006\02\08@144155 by Peter

picon face

On Tue, 7 Feb 2006, Denny Esterline wrote:

> Have we really _advanced_ to the point where we're discussing programming
> PICs with punch cards!?!

History repeats itself (at least for people who did not learn the
lesson the first time around ;-)

> Actually I like the phototransistor flash idea. Has anybody tried a LCD
> monitor?

If you try this think about low pass filtering. The spot will trip the
phototransistors several times per 'flash' in every frame in a crt. In a
lcd the backlight frequency will do the same.

Peter

2006\02\08@144825 by Peter

picon face

On Tue, 7 Feb 2006, William Chops Westfield wrote:

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

Peter

2006\02\08@144903 by Peter

picon face


On Tue, 7 Feb 2006, Peter Todd wrote:

{Quote hidden}

Dancing mat.

Peter

2006\02\08@160843 by David VanHorn

picon face
> 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"...

2006\02\08@175524 by Gerhard Fiedler

picon face
Juan Cubillo 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...

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

Gerhard

2006\02\09@131057 by Peter

picon face


On Wed, 8 Feb 2006, David VanHorn wrote:

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

Yup. With paper tape. Or two-track wax cylinder recording.

Peter

2006\02\09@134757 by David VanHorn

picon face
>
> Yup. With paper tape. Or two-track wax cylinder recording.


I see no reason you couldn't get at least 8 bit parallel going with the
music box approach.

2006\02\09@141225 by William Couture

face picon face
On 2/9/06, David VanHorn <TakeThisOuTdvanhornspamspammicrobrix.com> wrote:
> >
> > Yup. With paper tape. Or two-track wax cylinder recording.
>
>
> I see no reason you couldn't get at least 8 bit parallel going with the
> music box approach.

If you are going to use a music box for data storage, you should be
able to interface it with a *REAL* computer!

http://acarol.woz.org/

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2006\02\09@142929 by Tomas Larsson

flavicon
face
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?

With best regards

Tomas Larsson
Sweden

Verus Amicus Est Tamquam Alter Idem

> {Original Message removed}

2006\02\09@152220 by David VanHorn

picon face
On 2/9/06, Tomas Larsson <tomaslarssonseEraseMEspamyahoo.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?


You can get the Altair front panel as a USB peripheral now.

2006\02\10@150629 by Peter

picon face

On Thu, 9 Feb 2006, David VanHorn wrote:

>> Yup. With paper tape. Or two-track wax cylinder recording.
>
> I see no reason you couldn't get at least 8 bit parallel going with the
> music box approach.

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.

Peter

2006\02\10@160204 by Peter

picon face

On Thu, 9 Feb 2006, Tomas Larsson 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?

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

Peter

2006\02\13@041155 by Alan B. Pearce

face picon face
>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).

2006\02\13@133124 by Peter

picon face


On Mon, 13 Feb 2006, Alan B. Pearce wrote:

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

Peter

2006\02\14@021912 by Dmitriy Kiryashov

picon face
Hi Peter.

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


'[PIC] Cheap programmer interface, was noob's 1st q'
2007\01\17@164251 by Christopher Head
picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFrphYytrPjvMzl6YRApnnAJ9mz0aY7LgYG/ej+y2qubf44b75kQCbBgiP
5vk0h2OVzulu62K1VizuBAg=
=kzr0
-----END PGP SIGNATURE-----

2007\01\17@190236 by peter green

flavicon
face

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

{Quote hidden}

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.


2007\01\17@195044 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

[snip]


Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFrsRbytrPjvMzl6YRAqpyAJ98fcyT8PlNFIhvJj0/FfZpUgSHwgCfbYD+
Es9oABNPW+/rxPkPE19/wy0=
=1O+G
-----END PGP SIGNATURE-----

2007\01\18@012546 by Vasile Surducan

face picon face
On 2/3/06, Alan B. Pearce <RemoveMEA.B.PearceEraseMEspamspam_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.

Vasile

2007\01\18@044226 by Alan B. Pearce

face picon face
>On 2/3/06, Alan B. Pearce <@spam@A.B.PearceRemoveMEspamEraseMErl.ac.uk> wrote:

Grief, nearly a year ago I wrote something ...

Don't know Vasile, what that was about, but it sure isn't in my email
history here now. I cannot even remember if I wrote it, or what the original
subject line was.

2007\01\18@072521 by olin piclist

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


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\01\18@072601 by peter green

flavicon
face


{Quote hidden}

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


2007\01\18@074654 by Hazelwood Lyle

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

Lyle

2007\01\18@075458 by Vasile Surducan

face picon face
On 1/18/07, peter green <plugwashspamBeGonespamp10link.net> wrote:
{Quote hidden}

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

greetings,
Vasile

2007\01\29@201847 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Chris

Hazelwood Lyle wrote:
{Quote hidden}

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFvjkxytrPjvMzl6YRAqj7AJ9T3/vYnQsvSK8TetvpG9UxexbUAQCfa2CM
XDgYe9FFa5ZUGrCQi0fFJug=
=sPys
-----END PGP SIGNATURE-----

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...