Searching \ for '[PIC] ICD 2 clones - The Empire Strikes Back?' 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=icd
Search entire site for: 'ICD 2 clones - The Empire Strikes Back?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] ICD 2 clones - The Empire Strikes Back?'
2004\09\27@123407 by Ken Pergola

flavicon
face

I came across this statement in the Microchip Forums:

----
"Use caution with knockoffs since they reportedly won't work with MPLAB
starting with version 7.00."
(http://forum.microchip.com/tm.asp?m=54816&mpage=1&key=&anchor#54943)
----

Hmm, *if* this is true, it will be interesting to see if Microchip is
planning to squash the ICD 2 clones. Tune in to MPLAB IDE v7.00. I think
it's due near the end of November.

Best regards,

Ken Pergola




_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\28@063108 by Morgan Olsson

flavicon
face
Microchip stopped supporting their *own* ICD (ICD1) in recent MPLAB.
(Could not be too hard to *keep* existing support, could it??)
I guess that it was just to make the old ICD clones unusable.

Now, when there are several good ICD 2 clones, i guess Mchip tries to kill them too.  Just wondering if their own ICD2 really contiues to work.
(Why did they not uffer an upgrade firmware or MPLAB driver for the old ICD??)
When will I be forced to buy ICD3...?

/Morgan

Ken Pergola 18:34 2004-09-27:


{Quote hidden}

--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\28@071548 by Mike Harrison

flavicon
face
On Tue, 28 Sep 2004 12:30:43 +0200, you wrote:

>Microchip stopped supporting their *own* ICD (ICD1) in recent MPLAB.
>(Could not be too hard to *keep* existing support, could it??)
>I guess that it was just to make the old ICD clones unusable.
>
>Now, when there are several good ICD 2 clones, i guess Mchip tries to kill them too.  Just wondering if their own ICD2 really contiues to work.
>(Why did they not uffer an upgrade firmware or MPLAB driver for the old ICD??)
>When will I be forced to buy ICD3...?

I really don't think Microchip cares about clones - they are in the business of selling chips, not
devtools.
It costs them time, money, and effort to support obsolete hardware, so dropping support in new
releases makes sense. I doubt there is anything more to it than that.



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\28@130229 by Roland

flavicon
face
At 12:18 PM 28/09/2004 +0100, you wrote:

>I really don't think Microchip cares about clones - they are in the
business of selling chips, not
>devtools.

I really hope so. The reason they became sucessful is because they made it
easy to use their chips, be-it with a crappy paging system.
Proprietry philosophies suck, which is why you'd rather buy a Telefunken TV
rather than a Sharp (going back a few years)

Unless; maybe they consider themselves to have such a huge user base, that
it's now time to squeeze that loyalty for maximum profit?

Regards
Roland Jollivet

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\28@140334 by Robert Rolf

picon face
Mike Harrison wrote:

>>Microchip stopped supporting their *own* ICD (ICD1) in recent MPLAB.

Yeah, that was a piss off. So I continue to use an older
version of MPLAB because it's 'good enough'.

>>(Could not be too hard to *keep* existing support, could it??)
>>I guess that it was just to make the old ICD clones unusable.

Not enough of them out there to bother.
I think it was more a case of 'its older, lets forget about it'.

>>Now, when there are several good ICD 2 clones, i guess Mchip tries to kill them too.  Just wondering if their own ICD2 really contiues to work.
>>(Why did they not uffer an upgrade firmware or MPLAB driver for the old ICD??)
>>When will I be forced to buy ICD3...?

You are only 'forced' if you want to use their newer chips.
The ICD1 and ICD2 program the older chips just fine.
Having to buy YET ANOTHER programmer is a disincentive to
even LOOK at their new chips.

Or stop buying Microchip and use something else. AVR, etc.

> I really don't think Microchip cares about clones - they are in the
> business of selling chips, not devtools.

Agreed.

> It costs them time, money, and effort to support obsolete hardware,

No more so than to support NEW hardware.
People generally know how to use their OLD hardware and
already have it working correctly. Never underestimate the
resistance of inertia. If it ain't broke...

> so dropping support in new
> releases makes sense.

NO, IT DOESN'T! All it does is slap people who have remained
loyal to a particular manufacturer.

If I have to go out and buy new dev tools to use their new,
bigger chips, I am MUCH more inclined to look at competitors chips
since I'm out of pocket for new devtools in either case.
After all 'change is good'...

Unless there is a significant difference in the hardware requirements,
there is NO reason to NOT support new chips on the old programmers.
ICSP isn't THAT complex and the interface to EVERY ICSP capable
chip is basically the same: *MCLR, PGM, Clock and Data.

The ICD eventually received a firmware update to program the
16F8xxA devices by 'faking out' MPLAB 5.x.

There is NO GOOD REASON that the 6.* series of MPLAB
could not have supported it (ICD1) or for ICD2 to support
the latest chips with updated firmware.

>I doubt there is anything more to it than that.

Never attribute to malice what you can attribute to STUPIDITY!
Microchip, are you listening? Users LIKE their old programmers.
Users are comfortable with them, and want to continue to use them,
so SUPPORT them by providing whatever firmware/software updates
are needed to program the newer chips.

It's easy to buy loyalty. Just support the users existing programmers.

Robert

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@040826 by Alan B. Pearce

face picon face
>There is NO GOOD REASON that the 6.* series of MPLAB
>could not have supported it (ICD1) or for ICD2 to
>support the latest chips with updated firmware.

Especially when the chip in the ICD2 is the same as the one in the ICD1. The
major difference is the USB interface.

HOWEVER what I have not investigated is what the ICD2 can do with the Vpp
voltage. Is it adjustable, or is it fixed like the ICD1. That is about the
only difference that I can think of that might make them want to obsolete
the ICd1.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@043709 by Jan-Erik Soderholm

face picon face
> HOWEVER what I have not investigated is what the ICD2 can do
> with the Vpp voltage. Is it adjustable, or is it fixed like the ICD1.
> That is about the only difference that I can think of that might
> make them want to obsolete the ICd1.

What about maintaining a separate batch of engineering
documentation ? The adminstration and quality control
of the docs are a fair bit of the total cost of keeping an
old product line up-to-date.

After all, *every* company phases out old products now
and then...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@082522 by Howard Winter

face
flavicon
picon face
Jan-Erik,

On Wed, 29 Sep 2004 10:37:08 +0200 (CEST), Jan-Erik Soderholm wrote:

> The adminstration and quality control
> of the docs are a fair bit of the total cost of keeping an
> old product line up-to-date.

Indeed, plus keeping spares, and answering queries about it ("Will the ICD1 support the dsPIC range?") and
keeping someone trained in it.  Even just the floor-space taken up by the filing cabinets costs money when the
space could be used for something current.  Then there's the code in the software (MPLAB etc) that needs to be
maintained, with more branches and routines because of the legacy support.  The more options there are, the
more complex is the software support, even if changes don't affect the "old" code - you have to make sure that
that is the case, and test to makes sure nothing has been affected inadvertently.

> After all, *every* company phases out old products now and then...

Except water companies, hopefully!  :-)

Cheers,


Howard Winter
St.Albans, England


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@092659 by Jan-Erik Soderholm

face picon face
Howard Winter wrote :

> > After all, *every* company phases out old products now and then...
>
> Except water companies, hopefully!  :-)
>
> Cheers,
> Howard Winter

He, hm, well...

Water (if we are speaking about the water that comes out of
the kitchen tap, not bottled water) is one of the 3 or 4 things that
"companies" shouldn't be allowed to handle anyway. Together with
e.g. the basic road, electricity, train and (snail-) mail infrastructures...

Remember when the UK had a working railway system ? :-)

Companies are welcome to handle those things that you have a fair
chance to to say "no" to, if you want. Such as the IDC1 successor... :-)

Jan-Erik.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@135123 by Robert Rolf

picon face
Alan B. Pearce wrote:
>>There is NO GOOD REASON that the 6.* series of MPLAB
>>could not have supported it (ICD1) or for ICD2 to
>>support the latest chips with updated firmware.
>
> Especially when the chip in the ICD2 is the same as the one in the ICD1. The
> major difference is the USB interface.

Yes, and the firmware to drive it.

> HOWEVER what I have not investigated is what the ICD2 can do with the Vpp
> voltage. Is it adjustable, or is it fixed like the ICD1. That is about the

ICD1 Vpp is NOT fixed. The firmware runs a software PWM boost
convertor to create regulated Vpp from Vcc.
I assume the ICD2 is similar.

> only difference that I can think of that might make them want to obsolete
> the ICd1.

I don't think that's the reason. More likely the engineer
responsible has 'moved on' and nobody there wants work on 'old stuff'.


Robert

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\29@142736 by Bob Ammerman

picon face
The ICD1 was not engineered or designed my mChip, but by Transdata(??) IIRC.
I have a feeling that it was always viewed by mChip as an interim solution,
and that wanted something a bit more polished (ie: the puck!).

Bob Ammerman
RAm Systems

{Original Message removed}

2004\09\30@052630 by Mike Harrison

flavicon
face
.
>> I really don't think Microchip cares about clones - they are in the
> > business of selling chips, not devtools.
>
>Agreed.
>
>> It costs them time, money, and effort to support obsolete hardware,
>
>No more so than to support NEW hardware.

They produce new hardware to cover a wider range of chips and/or add new features. This often
involves making changes that are not back compatible to the old hardware. Additional effort would be
required to support the old hardware, which is not justified when the cost of upgrading to new
hardware is pretty low. They continued support for the Picmaster long after MPLAB-ICE came out
because it was a large investment. ICDs are not.  
There is always _some_ effort, therefore cost needed to support obsolete hardware, even if it;s just
testing.  

>People generally know how to use their OLD hardware and
>already have it working correctly. Never underestimate the
>resistance of inertia. If it ain't broke...

Not  a major issue if the new harware works pretty much like the old stuff did.

> > so dropping support in new
>> releases makes sense.
>
>NO, IT DOESN'T! All it does is slap people who have remained
>loyal to a particular manufacturer.

Nonsense.  People can still use the older software if they really don't want to spend the relatively
small amount on new hardware. Customers that won't spend $200 on devtools are not going to be very
crucial to their bottom-line.

>If I have to go out and buy new dev tools to use their new,
>bigger chips, I am MUCH more inclined to look at competitors chips
>since I'm out of pocket for new devtools in either case.
>After all 'change is good'...

This is only the case if the devtools are expensive. ICD2 costs peanuts compared to overall
development costs.


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@080151 by Morgan Olsson

flavicon
face
Mike Harrison 11:29 2004-09-30:
>>> I really don't think Microchip cares about clones - they are in the
>> > business of selling chips, not devtools.

FWIW, I also have to change back to elder MPLAB when needing to edit or even just programming PIC14000 for an old project that refuse to die.  :/  (using Mchip tools)

And I keep one middle aged MPLAB version for ICD1.

And install latest MPLAB for newer chips and ICD2.

Soon i guess will have another version for other chip old-project support, and later one that supports ICD3 but not ICD2...?

Golden rule: always save development tools install files with the project!

(Maybe also OS system, patches...  ;) )

Question:
Where can we find a table/list of chip and tool support, maybe even issues/improvements in various MPLAB versions?

/Morgan
--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@090824 by Mike Harrison

flavicon
face
On Thu, 30 Sep 2004 14:00:59 +0200, you wrote:

{Quote hidden}

I still run 5.7 for Picmaster support, and have on occasion also needed 5.3 (can't remember the
reason now...!)

Does anyone know if there was there a 5.x version after 5.7, as 5.7 has problems during project
setup that means I often have to manually edit .pjt files to work properly.....



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@101922 by Ken Pergola

flavicon
face

Mike Harrison wrote:

> Does anyone know if there was there a 5.x version after 5.7, as
> 5.7 has problems during project
> setup that means I often have to manually edit .pjt files to work
> properly.....


Hi Mike,

Yes there was. The last 16-bit MPLAB IDE I have archived is v5.70.40. You
should be able to find this version on Microchip's web site in the archives.
I think that is the last *16-bit* version that Microchip publicly released.


In addition, I have 3 versions of the *32-bit* MPLAB IDE archived:

v5.95.10
v5.95.12
v5.95.14

I'm pretty sure these were "early adopter" versions of the 32-bit MPLAB IDE
before MPLAB 6.00 was publicly released.

Best regards,

Ken Pergola


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@125907 by Robert Rolf

picon face
Mike Harrison wrote:

> They produce new hardware to cover a wider range of chips and/or add new features.

WHAT 'new features'? Programming is programming. Debugging is debugging.
The only thing changing is the subtleties of the ICSP commands to
accommodate bigger chip memories and new? debug registers.

> This often
> involves making changes that are not back compatible to the old hardware.

Again, WHAT changes would NOT be supportable when the 'old' hardware
has updatable firmware? The beauty of ICSP is that the interface
DOESN'T CHANGE. Only the protocol might, and that is firmware fixable.

> Additional effort would be
> required to support the old hardware,

Only a slight effort. As noted before, changed programming
algorithms are accommodated by updating the firmware.

> which is not justified when the cost of upgrading to new
> hardware is pretty low.

Why HAVE to buy new hardware, when firmware updates can
usually do the job? Or a user applied 'hack' (as for the
Motorola EVM boards or ICD's to get LV support).

>  They continued support for the Picmaster long after MPLAB-ICE came out
> because it was a large investment. ICDs are not.

EXACTLY!!!
Because ICD's are 'cheap' Microchip sees little value in
keeping them running with free updates, when then can SELL
you NEW hardware.

Whatever happened to the 1990's mantra, "reduce, recycle, reuse".
Being able to REUSE an older programmer with nothing more than
newer firmware is ecologically a 'good thing'.


> There is always _some_ effort, therefore cost needed to support
> obsolete hardware, even if it;s just testing.

True.
But what is the offloaded cost of requiring users to have
to purchase thousands of new programmers, if one wants to
use newer chips?

>>People generally know how to use their OLD hardware and
>>already have it working correctly. Never underestimate the
>>resistance of inertia. If it ain't broke...

> Not  a major issue if the new harware works pretty much like the old stuff did.

The inertia I speak of is 'if it ain't broke why am
I having to buy a new one'?

I rather doubt that you'd be happy about having to buy new
vehicle tires in order to use a new freeway. Or then have
to change them back in order to drive on your old freeway.
After all, the tires are only a small part of the overall
cost of the vehicle, so it should be no problem to buy new
ones every time you need to use a 'new' freeway.

>>>so dropping support in new
>>>releases makes sense.
>>
>>NO, IT DOESN'T! All it does is slap people who have remained
>>loyal to a particular manufacturer.
>
> Nonsense.  People can still use the older software if they really
> don't want to spend the relatively small amount on new hardware.

Not if they want to use the newer chips.
People DO look at TCO (total cost of ownership), so if I see
that a new programmer is needed for every new device line,
I'm less likely to buy into it.

> Customers that won't spend $200 on devtools are not going to be very
> crucial to their bottom-line.

You never know...

One of the reasons the PIC has such a wide user base is that
it was trivially easy and inexpensive to build a programmer
for it (16F84 & Tait parallel port pgmr). Hobbyists could
easily get started, and engineers could cheaply experiment.

Once people learn an architecture well, they tend to stick with it.
Motorola knew this, and provided good support to educators back
in the late 1908's. As a result many engineering faculties used
Motorola CPU's in their courses and graduate engineers could ONLY think
Motorola when employed, sometimes to the detriment of finding the
'best' solution in some cases. (having worked with one of these
new engineers, I've seen it first hand).

>>If I have to go out and buy new dev tools to use their new,
>>bigger chips, I am MUCH more inclined to look at competitors chips
>>since I'm out of pocket for new devtools in either case.
>>After all 'change is good'...
>
> This is only the case if the devtools are expensive.
> ICD2 costs peanuts compared to overall
> development costs.

True, but that means one more programmer taking up space.
On more P.O. to generate and process, etc. One more user
interface to learn...

I guess I just have a REAL problem with 'forced obsolecense'.

Robert

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@152004 by Jan-Erik Soderholm

face picon face
Robert Rolf wrote :

> > Additional effort would be
> > required to support the old hardware,
>
> Only a slight effort. As noted before, changed programming
> algorithms are accommodated by updating the firmware.

I think you are missing the point.
I cost *a lot* to keep a product just living, even if you do not
change it a bit. And even more, of course, each time you have to
make a change to it.


> Because ICD's are 'cheap' Microchip sees little value in
> keeping them running with free updates, when then can SELL
> you NEW hardware.

And each new IDCx would cost more if they'd had to keep supporting
all old models at the same time.

> > This is only the case if the devtools are expensive.
> > ICD2 costs peanuts compared to overall development costs.
>
> True, but that means one more programmer taking up space.

Now, I don't know this in detail, but tell me. Why keep the IDC1
when you gets an IDC2 ?

> On more P.O. to generate and process, etc.

Yes, once each 2, 3 or 4 (?) years. A hell of a lot of work...

> One more user interface to learn...

One *new* user interface, maybe, but why one *more* ?
Again, why keep the IDC1 ? Is there something the IDC1
can do that the IDC2 can't ?

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@162543 by Peter Johansson

flavicon
face
Jan-Erik Soderholm writes:

> I think you are missing the point.
> I cost *a lot* to keep a product just living, even if you do not
> change it a bit. And even more, of course, each time you have to
> make a change to it.

I'd like to bring this discussion full-circle for a second.  The
original reference was whether or not the ICD2 clones would work with
the upcoming release of MPLAB.  I chose the word "work" rather than
"supported" because even the current clones which do *work* are in no
way *supported* by Microchip.

I have not done any type of intensive analysis of the Olimex clone
vs. the original Microchip ICD2 and my recollection is that the boards
are the same size and have the same chip layout.  I don't believe the
ICD2 uses any special components, so it seems not unreasonable that
the Olimex people simply reproduced the same circuit, perhaps even
using the same PCB layout.  It seems logical, therefore, that if this
were the case, all future updates would work on the clones, or at
least the Olimex clone.

Can anyone comment on this?  Does anyone happen to know if the Olimex
board is a 100% clone of the ICD2?  This effects me personally because
I was only moments away from ordering the Olimex board when I saw this
thread.

I'm still learning microcontrollers with the Parallax SX toolkit, and
while this is a *wonderful* learning environment, I think I would be
using PICs in my actual projects.  In most cases I don't need the
speed of the SX, and the ability to choose a small cheap component
like the 12F629 or one with lots of IO like the 18F452 (without having
to go SMD) is a real plus.

I've also been investigating the AVRs, and, at the risk of heresy,
they seem to have a lot of advantages over the PIC line.  While the
line doesn't seem to be as extensive as the PIC it is *far* better
than the SX, the architecture is a little more sane, there are free
compilers (gcc!) and they seem to be priced comparably with the PICs
in terms of I/O features, yet always providing more memory and greater
computing throughput.

It's enough to make the think my next development kit might be Atmel
instead of PIC...

-p.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\09\30@165702 by Mike Harrison

flavicon
face
On Thu, 30 Sep 2004 10:59:00 -0600, you wrote:

>Mike Harrison wrote:
>
>> They produce new hardware to cover a wider range of chips and/or add new features.
>
>WHAT 'new features'? Programming is programming. Debugging is debugging.
>The only thing changing is the subtleties of the ICSP commands to
>accommodate bigger chip memories and new? debug registers.
>
>> This often
>> involves making changes that are not back compatible to the old hardware.
>
>Again, WHAT changes would NOT be supportable when the 'old' hardware
>has updatable firmware? The beauty of ICSP is that the interface
>DOESN'T CHANGE.
Yes it does sometimes -  12F parts have Vcc sequencing requirements that earlier parts didn't.
And anyway I was talking about the protocol to the ICD, which there may well be very good reasons to
change.

>Only the protocol might, and that is firmware fixable.
It costs time to change firmware. Why spend time on obsolete hardware, when there is better hardware
(e.g. because it has USB)  available to do the same job?

Microchip HAVE continued support for devices like Picstart, and I don't think they are any better or
worse than most other suppliers.
Look at how many ICEs Atmel have been through, for example....
ICEPRO, ICE200,ICE40,ICE50, then JTAG-ICE 1 and now JTAG-ICE 2......



_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


'[PIC] ICD 2 clones - The Empire Strikes Back?'
2004\10\01@010434 by William Chops Westfield
face picon face
On Sep 30, 2004, at 1:59 PM, Mike Harrison wrote:
>>
>> Again, WHAT changes would NOT be supportable when the 'old' hardware
>> has updatable firmware? The beauty of ICSP is that the interface
>> DOESN'T CHANGE.
>>
Well, for instance, how long do you think microchip wants to keep on
supporting PC serial ports, as more and more motherboards don't have
them, and the path between the CPU and a serial device becomes more
and more convoluted by random vendors' less-than-standard products?

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@024845 by Morgan Olsson

flavicon
face
William "Chops" Westfield 07:04 2004-10-01:
>Well, for instance, how long do you think microchip wants to keep on
>supporting PC serial ports,

Serialports is possible and easy to optoisolate.
For the current project i can not use USB in final test as the PIC cirquitry is on high voltage.

Another route would be if future ICD use ethernet = isolated by default :)
I guess that will be in ICD3 ;)
...and ICD4 will have Bluetooth, but no serial, no USB, and the ethernet was too expensive so it also gets dropped again...

Just waiting for the brainwave ICD so I can just think the program, mentally debug, and program.  :)

/Morgan
--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@032311 by Robert Rolf

picon face
Morgan Olsson wrote:

> William "Chops" Westfield 07:04 2004-10-01:
>
>>Well, for instance, how long do you think microchip wants to keep on
>>supporting PC serial ports,
>
> Serialports is possible and easy to optoisolate.

Very easy and cheap.

> For the current project i can not use USB in final test as the PIC cirquitry is on high voltage.

http://www.bb-elec.com/product.asp?sku=UISOHUB4

"Model UISOHUB4 is a four port USB hub with 2500 VAC isolation. Both
high and low speed USB peripherals are supported as well as high powered
and low powered devices. $280 USD"

> Another route would be if future ICD use ethernet = isolated by default :)

Only to 400V if memory serves.
With fiber based gigabit interface, 10's of KV possible.

> I guess that will be in ICD3 ;)

Probably.

> ...and ICD4 will have Bluetooth, but no serial, no USB, and the ethernet was too expensive so it also gets dropped again...

Probably too.

> Just waiting for the brainwave ICD so I can just think the
program, mentally debug, and program.  :)

I work in a lab where we do some of that <G>. My boss thinks it,
and I get to make it happen.

R

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@045002 by Alan B. Pearce

face picon face
>> This often involves making changes that are
>> not back compatible to the old hardware.
>
>Again, WHAT changes would NOT be supportable when the
>'old' hardware has updatable firmware? The beauty of
>ICSP is that the interface DOESN'T CHANGE. Only the
>protocol might, and that is firmware fixable.

This is the point I was making, when I pointed out that the ICD1 and the
ICD2 have the same chip internally. There is nothing in the ICD2 that the
ICD1 doesn't have, apart from a "not invented here" problem, as someone else
pointed out. However Microchip have provided updates for the ICD1 to speed
it up, and handle the 877A, so I doubt there is serious licensing issues
with Transdata.

Someone else pointed out that the ICD2 has USB interface, but that is
handled by a separate chip. There is sweet all reason that I can see why the
ICD1 cannot be treated as a serial interface only ICD2.

Hmm, now there is a point, how can I download the ICD2 software into an
ICD1? I guess the pins used for various functions are different, so it won't
be a straight plug in. Might have to investigate this.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@114558 by Morgan Olsson

flavicon
face
Alan B. Pearce 10:51 2004-10-01:
>when I pointed out that the ICD1 and the
>ICD2 have the same chip internally.

ICD: 16F876 (programmed with latest (?) firmware for ICD1 (using Picstart+))
ICD2: 16F877A

Probably due to extra pins for USB chip and more status LEDs

/Morgan
--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@121830 by Alan B. Pearce

face picon face
>ICD: 16F876 (programmed with latest (?)
>firmware for ICD1 (using Picstart+))
>ICD2: 16F877A
>
>Probably due to extra pins for USB chip and more status LEDs

Ahh, yes point taken, I had forgotten they had gone to the 40 pin chip.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@122048 by Morgan Olsson

flavicon
face
Robert Rolf 09:23 2004-10-01:
>Morgan Olsson wrote:
>
>>William "Chops" Westfield 07:04 2004-10-01:
>>
>>>Well, for instance, how long do you think microchip wants to keep on
>>>supporting PC serial ports,
>>Serialports is possible and easy to optoisolate.
>
>Very easy and cheap.
>
>>For the current project i can not use USB in final test as the PIC cirquitry is on high voltage.
>
>http://www.bb-elec.com/product.asp?sku=UISOHUB4
>
>"Model UISOHUB4 is a four port USB hub with 2500 VAC isolation. Both high and low speed USB peripherals are supported as well as high powered and low powered devices. $280 USD"

Wow.  They are coming :)  Expensive though.

>>Another route would be if future ICD use ethernet = isolated by default :)
>
>Only to 400V if memory serves.

I dont know what (or where) the spec is. Seen ethernet transformers rated 1kV, but...  anyhow ethernet cables are not rated mains voltage...

>With fiber based gigabit interface, 10's of KV possible.

Yes... megavolts...
unless the fiber is steel armored...


{Quote hidden}

:)
--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@132524 by Kenneth Lumia

picon face
"Morgan Olsson" wrote:

> Serialports is possible and easy to optoisolate.
> For the current project i can not use USB in final test as the PIC
cirquitry is on high voltage.
>

Actually, it is relatively simple and not much more expensive to isolate the
USB
port.  I did this on a project for a Circuit Cellar competition and it
proved
rather easy.  Take your USB and use a FT232BM chip to convert USB
to serial.  Add 2 optocouplers for TX and RX and connect the other side
to the projects serial port.  In my case, it was an AVR, however a
PIC would be similarly wired.  If you lay it out correctly, the worst
case isolation is the optocouplers rating.

Ken
spam_OUTklumiaTakeThisOuTspamadelphia.net


{Original Message removed}

2004\10\01@132740 by Robert Rolf

picon face
Alan B. Pearce wrote:
>>ICD: 16F876 (programmed with latest (?)
>>firmware for ICD1 (using Picstart+))
>>ICD2: 16F877A
>>
>>Probably due to extra pins for USB chip and more status LEDs
>
> Ahh, yes point taken, I had forgotten they had gone to the 40 pin chip.

But if the extra pins are for the USB & LED's, it should not be
that big a deal to disassemble the code and modify it to run
on ICD1 hardware.

Anyone have quick pointers to the ICD2 schematic and hex file?
I don't suppose anyone has disassembled the ICD1 & 2 code yet.
I expect that 90% of it will be the same except for the USB.
Or are there more substantial differences about ICD2 hardware?

Hmmm, DIY ICD2 with nothing more than a firmware update to ICD1.
Hadn't thought of that approach. If the mountain won't come to
Mohhamed....

Robert

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\01@151133 by Igor Pokorny

flavicon
face
Well, I played awhile with an idea to change firmware to my ICD1 to be
able to communicate with MPLAB 6.xx  There are two firmwares and in
addition to the Mplab communication. Additional pins aren't a problem
'cause they are used for USB only. The main problem is controlling Vpp
and Vdd to the target. It's not possible to use ICD1 without some
changes on the board to be able to do that MPLAB 6.x asked for.
I considered to buy a clone instead.

Regards

Igor



{Original Message removed}

2004\10\02@041646 by Morgan Olsson

flavicon
face
Correction:   MPLAB 5.70.40 is the latest to support ICD1 and also latest to support PIC14000.

So it seems
http://ww1.microchip.com/downloads/en/DeviceDoc/mp57040full.zip
is good to have archived.

/Morgan

I wrote 14:00 2004-09-30:
>FWIW, I also have to change back to elder MPLAB when needing to edit or even just programming PIC14000 for an old project that refuse to die.  :/  (using Mchip tools)
>
>And I keep one middle aged MPLAB version for ICD1.

--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@041722 by Morgan Olsson

flavicon
face
Kenneth Lumia 19:25 2004-10-01:
>Take your USB and use a FT232BM chip to convert USB
>to serial.  Add 2 optocouplers for TX and RX and connect the other side
>to the projects serial port.

Actually I was talking of making the *ICD* isolated, for debugging running at mains voltage.

According to Microchip the ICD (not clear if it is ICD 1 or 2) also use CTS, RTS, and DTR.  Can the FT232BM supply theese signals too?

Will MSWindows/Linux recognize a plugged in FT232BM as a generic "USB serial port" without any programming?

/Morgan
--
Morgan Olsson, Kivik, Sweden

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\02@051443 by Wouter van Ooijen

face picon face
> According to Microchip the ICD (not clear if it is ICD 1 or
> 2) also use CTS, RTS, and DTR.  Can the FT232BM supply theese
> signals too?

yes

> Will MSWindows/Linux recognize a plugged in FT232BM as a
> generic "USB serial port" without any programming?

I had to install the FTDI VCP driver to make this work, folks say that
such a driver is part of the newer XP's.

Wouter van Ooijen

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


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\03@120538 by Peter L. Peres

picon face

On Sat, 2 Oct 2004, Wouter van Ooijen wrote:

>> According to Microchip the ICD (not clear if it is ICD 1 or
>> 2) also use CTS, RTS, and DTR.  Can the FT232BM supply theese
>> signals too?
>
> yes
>
>> Will MSWindows/Linux recognize a plugged in FT232BM as a
>> generic "USB serial port" without any programming?
>
> I had to install the FTDI VCP driver to make this work, folks say that
> such a driver is part of the newer XP's.

I am looking (more than looking) at FTDI RS232 and parallel interfaces
more and more and I'd like to know what drives these under Linux ?
Hotplug->usb serial and done ? Or else ?

Peter
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

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