He tells me he has difficulties to promote the dsPICs
because the customers complains that there are too few
examples on the net. I tell him that most of the examples
on the net are provided by hobbyists. Therefore they
need to do something to help the hobbyists in order to
help themselves.

I tell him there are now some barriers.

1) Programmer support: ICD2 may still be too expensive for
quite some hobbyists. They need to support sub US$50
programmers like Wisp628, EasyISP and PICkit 2. For example
I am only empowered to buy anything below US$60 by my wife. :(

2) Application notes: there are now not too much application
notes. For example, something like dsPIC bootloader will help
a lot. Now most of the application notes are dealing with
motor drive only.

3) Price of the parts: they are a bit pricey now. Anyway, the
sampling program is quite okay.

4) C30 compiler: not free. But the demo lasts 60 days. The
assembler is free though.

5) Linux support: It is difficult for Microchip to support Linux
publicly. However I know inside Microchip there are quite some
people who want to support the Linux community in some way.

Any other thoughts? He will collect the opinions and feedback to
Microchip USA.

> Any other thoughts? He will collect the opinions and feedback to
> Microchip USA.

For more examples on the net: how about a contest aimed at hobbyist (for
instance: estimated price of total project must be < $25).

Years ago at an introduction of the dsPICs I heard rumours of an
mpeg-decoder library. If that would be available (and cheap, re C30), I
think home-brew mpeg players (there are lots and lots of such designs,
but mostly with AVR + mpge decoder chip) would love to use the dsPIC.

About Wisp628 (more like Wisp648) support for dsPICs: if a certain
person had not kept bugging me about updating Wisp628 I would probably
have postponed it a 'little' more. If uChip had bombarded me with
samples of all new chips I would probably have felt obliged to do
something with them. I would suggest that they select a few 'promising'
programmer designs and simple send a few samples of each new PIC chip to
the developers. Suggestions that I can think of right now: myself (of
course), Olin, Kitsrus, Warp, ic-prog, pony-prog (yes, those ones too!).

>-----Original Message-----
>From: spam_OUTpiclist-bouncesTakeThisOuTmit.edu [.....piclist-bouncesKILLspam@spam@mit.edu]
>Sent: 25 August 2005 09:50
>To: 'Microcontroller discussion list - Public.'
>Subject: RE: [PIC] dsPIC for hobbyists
>
>
>> Any other thoughts? He will collect the opinions and feedback to
>> Microchip USA.
>
>For more examples on the net: how about a contest aimed at
>hobbyist (for
>instance: estimated price of total project must be < $25).
>
>Years ago at an introduction of the dsPICs I heard rumours of
>an mpeg-decoder library. If that would be available (and
>cheap, re C30), I think home-brew mpeg players (there are lots
>and lots of such designs, but mostly with AVR + mpge decoder
>chip) would love to use the dsPIC.

I think the current consumption would be a big issue for a portable player however.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

I will add PICkit 2 to the list as well. :)
Anyway I think Microchip is planning to support
PIC18/PIC18J/dsPIC for PICkit 2 judging from the
PC application (now grayed out) but I do not
know the time frame. Hopefully not year 2010. :)

Some questions to Wouter:

When will be Wisp648 (or better Wisp2550) be out?

When will the PICkit 2 clone be out?

Warp? It is out of the business even though the
author still supports it. Right?

At 10.50 2005.08.25 +0200, you wrote:
>> Any other thoughts? He will collect the opinions and feedback to
>> Microchip USA.
>
>For more examples on the net: how about a contest aimed at hobbyist (for
>instance: estimated price of total project must be < $25).
>
>Years ago at an introduction of the dsPICs I heard rumours of an
>mpeg-decoder library. If that would be available (and cheap, re C30), I
>think home-brew mpeg players (there are lots and lots of such designs,
>but mostly with AVR + mpge decoder chip) would love to use the dsPIC.
>
>About Wisp628 (more like Wisp648) support for dsPICs: if a certain
>person had not kept bugging me about updating Wisp628 I would probably
>have postponed it a 'little' more. If uChip had bombarded me with
>samples of all new chips I would probably have felt obliged to do
>something with them. I would suggest that they select a few 'promising'
>programmer designs and simple send a few samples of each new PIC chip to
>the developers. Suggestions that I can think of right now: myself (of
>course), Olin, Kitsrus, Warp, ic-prog, pony-prog (yes, those ones too!).

Aren't you able to connect to http://samples.microchip.com and request
3 units * 8 different chips every 30 (student) or 40 (otherwise) days?
And I mean FREE samples.

> Aren't you able to connect to http://samples.microchip.com and request
> 3 units * 8 different chips every 30 (student) or 40 (otherwise) days?
> And I mean FREE samples.

Yes, of course I can, if I want, take the time for it, remember when the
period is over, know what new chips there are, etc. But I was talking
about what uChip could do if they wanted to stimulate availablility of
lower-cost development tools. More like pestering would-be 30F tool
developers into activity.

Years and years ago when I was developing WISP and the first steps of
Jal (I was still just a hobbyist then) I got a free PS+ and some samples
from uChip, I don't remember whether I asked for them, or some 3d party
suggested it to uChip, or it was their own initiative. This did
stimulate me a lot, both technically (now I could use a know-good
programmer as comparison) and by feeling taken serious by the big
company. There are bound to be would-be tool developers out that that
could use such a push.

Some more about activating would-be tool developers: how about ...
- stimulating (paying?) someone/some group to create a GCC for the
12/14/16 bit cores?
- releasing a free GCC for the 30Fs without the optimization but with
the libraries?
- bombarding Scott (or who someone else) with PIC samples untill he
finishes SDCC?
- bombarding some Jal-developers (not me) with 30F samples until Jal
supports the 30F?

>> Ic-prog? Is it a programmer or just a software?
>
> it is just softwaree, but it suppports a wide range of (too) simple
> hardware (the typical serial-port pin-wiggling proggers). Not my
> recommended choice, but it is what a lot of starters use.

There are a bunch in that class. If you look at ic-prog, winpic, winpicprog
and the like, probably 75-95% of all hobbyists at least started with that
sort of approach. Today perhaps a USB programmer makes more sense, but if
you want to penetrate the hobbyist market, then you need to be looking at
the non-proprietary programmers, no matter how bad an idea you think that
is.

But if you (i.e. Microchip) take a disdainful attitude toward the "typical
serial-port pin-wiggling proggers" then you are writing off virtually all
the hobbyists, save the tiny few with understanding wives.

All in all, you have great ideas. I will summarize all the suggestions
and send them to Microchip! Any people know the people in the Microchip
tools group or dsPIC group? I only have the name card of a VP in
the SMTD division. :( Never mind, I will send it to the local Microchip
sales engineer first.

> > - releasing a free GCC for the 30Fs without the
> optimization but with
> > the libraries?
> According to the post in Microchip Forum, it is possible
> already. Please
> check the following thread.
> http://forum.microchip.com/tm.asp?m=94243

Maybe, but to stimulate, why not make an installable download available?

> > and of course, as said, open up the uChip tools for Linux....
> > Wouter van Ooijen
> This would be quite difficult due to their company policy and I
> think the support is not so easy and it requires lots of resources.

I think just making the communication interface of the various tools
available (maybe by NDA) would help a lot.

> and of course, as said, open up the uChip tools for Linux....
They're based around COM and ActiveX and proprietary M$ crapware like that.
You'd be better off rewriting MPLAB for Linux, but it would be nice if Mchip
helped out a little. "Here's the ICD2 protocol. Here's the firmware source.
Here's some code to run/stop/program/singlestep/watch..."

one more suggestion: besides bombarding prospects with sample chips, the
occasional *printed* datasheet would also be usefull. This might seem
not needed in this age of internet and pdfs, but just the programming
specifications of all PICs is quite a pile when printed, I am not sure
the complete datasheets would fit in my work room. They might argue that
you don't need them all. I would love that being true, maybe they could
force the documentation department to go to a reference doc / specifics
doc style!

> Maybe, but to stimulate, why not make an installable download available?

Maybe it's just my lack of knowledge, but from my perspective, making an
rpm, or even an installable tarball, is a lot more of a pain than running
InstallShield. And for maybe 10% of the market? Fairly hard to justify.

But amidst all the things a positive note, a thing they probably should
not change: their sampling program is excellent, much appreciated by
hobbyists. In time that alone might blow AVR and the 8051's out of the
hobbyist field!

I have a webshop selling PICs (and a lot of related things). One might
think this free samples program would hurt me, but I think that is not
the case. Free samples attract new hobbyists to PICs (who might
otherwise have bought from me, but maybe would not have considered PICs
are all), but for larger numbers (10 or so) they will still have to go
to some shop. And they need stuf beside the PICs, like crystals,
resonators, LCDs, max232, etc, which I sell :)

> > - stimulating (paying?) someone/some group to create a GCC for the
> > 12/14/16 bit cores?
>
> You'd be better off basing it on SDCC. GCC (IIRC) code
> generally requires a 32-bit architecture to run on.

No, a 16-bit arch is fine, but the GCC assumes a register architecture,
not a single-accumulator architecture like a 12/14 PIC. So it won't be
as easy as adding a 'typical' processor.

But note that for hobby use it need not be as effective (in terms of
code density) as a commercial compiler (it might even be a good idea to
keep the commercial compiler companies interested in PICs!), provided
that it is reliable (in terms of correctness of the produced code).

> Hell, I'd pay him to do it!

contact him! (or the others who are mention in another post)

> > - bombarding some Jal-developers (not me) with 30F samples until Jal
> > supports the 30F?
>
> Yeah... That sounds like a good plan. But why opt out of the fun? :D

> > Maybe, but to stimulate, why not make an installable
> download available?
>
> Maybe it's just my lack of knowledge, but from my
> perspective, making an
> rpm, or even an installable tarball, is a lot more of a pain
> than running
> InstallShield. And for maybe 10% of the market? Fairly hard
> to justify.

? I don't recognise those terms, I was suggesting something a Windoze
slave like me can download and double-click and be done with it.

>> one more suggestion: besides bombarding prospects with sample chips, the
>occasional *printed* datasheet would also be usefull.
>
It would also be very useful, in the case of a new chip that most people
are not using, for the programming examples that they put in the
datasheets to actually work! Let a newbie try the example before it is
published. There are lots of us that would be willing to do that. A
professional who just dashes off an example to be printed on a datasheet
may well leave something off because it is obvious to him (or her) that
thus-and-thus must be done and any fool would know that, and so why
bother to put it in the example. And if Wouter, for example, looks at
the example he will just say "Oh, they forgot to mention that you need
to do thus-and-thus," and go on and do it anyway. But when I look at
the example, I assume that they way they have it is just exactly how it
is supposed to be. (Which is why it took me two days to debug my timer
code).

>>I have a webshop selling PICs (and a lot of related things). One might
>think this free samples program would hurt me, but I think that is not
>the case. Free samples attract new hobbyists to PICs (who might
>otherwise have bought from me, but maybe would not have considered PICs
>are all), but for larger numbers (10 or so) they will still have to go
>to some shop. And they need stuf beside the PICs, like crystals,
>resonators, LCDs, max232, etc, which I sell :)
>
>
When I first got started with this, I bought stuff from you for the
simple reason that you had so much useful material at your website about
how to get started, that it just seemed the proper thing to do. :-)

1) Its fast, with hardware multiply and divide, which is very useful on
some apps.

2) Ram access is a bit less confusing, with no banking

However

1) Current consumption is a little on the high side.. (chip runs hot!
And its normal apparently)

2) The examples are really, really spare. To make things worse, the
dsPIC architecture is not nearly as simple as the 18f or 16f, with a DSP
instructions and that really badly documented set of byte wise rather
than worse wise operations. I had to find by trial and error in some
cases because of bad docs! Until I found the answer hidden in some
appendix in another set of docs.

Personally I find the price reasonable, but that's partially because as
a hobbyist I do mainly purchases of about 3-5 pieces so its not really a
problem.

As for programmer, I actually built a clone ICD2 for about $50 Singapore
dollars. However once I got my bootloader working I never really had to
take it out again.

I'm trying to get hold of a copy of the Masters presentations - especially
the one on OO coding in assembler. Tried the local MChip folk for a CD, and
the response I have is that only enough were made for the Masters. He is
going to try and find something for me.

But perhaps it would help popularise things if they made the Masters stuff
more freely available like past years.

Not really. The problem with GCC is that the RTL language upon which it is
based is somewhat obscured and intimidates those who'd want to create a
new port. Most people start (I imagine anyways) by copying an existing
port, but there really aren't any existing ports to use as templates for
the PIC architecture. (Although, I haven't looked in detail at Microchip's
dsp30 port). So figuring out how to properly model stuff like banked
registers and INDF/FSR indirect addressing would be challenging. I suspect
that Microchip primarily uses GCC as a C parser; just enough of the
backend was written to probably create one-to-one mapping of stock GCC RTL
objects into dsp30 assembly snippets. Then the real work of generating the
commercial quality assembly code is in their proprietary optimizer.

> - releasing a free GCC for the 30Fs without the optimization but with
> > the libraries?
>
> That would be nice

By the time I'm done, you could've bought everyone on the PICList a copy
of HiTech C! I haven't looked at SDCC seriously for a couple of years now.
But based on the number and type of bugs I see reported on the PIC port,
I'd estimate it'd take a full time professional programmer at least 6
months to get the PIC port generating commercial quality code. Most of the
effort here is just designing tests that check all of the corner cases.
BTW, 6 months ~ 1000 Man hours * $120/Hour = $120,000 at a minimum. Okay,
I think you can exclude the PICList lurkers from getting their free copy
of HiTech C. :)

At 12.43 2005.08.25 +0200, you wrote:
>> Aren't you able to connect to http://samples.microchip.com and request
>> 3 units * 8 different chips every 30 (student) or 40 (otherwise) days?
>> And I mean FREE samples.
>
>Yes, of course I can, if I want, take the time for it, remember when the
>period is over, know what new chips there are, etc. But I was talking
>about what uChip could do if they wanted to stimulate availablility of
>lower-cost development tools. More like pestering would-be 30F tool
>developers into activity.
>
>Years and years ago when I was developing WISP and the first steps of
>Jal (I was still just a hobbyist then) I got a free PS+ and some samples
>from uChip, I don't remember whether I asked for them, or some 3d party
>suggested it to uChip, or it was their own initiative. This did
>stimulate me a lot, both technically (now I could use a know-good
>programmer as comparison) and by feeling taken serious by the big
>company. There are bound to be would-be tool developers out that that
>could use such a push.

<IMHO> Microchip is doing more than a lot with its samples program, and
pretending that they even ring at your door unexpectly may look a tad
excessive </IMHO>

What would the competitors say? "Microchip is so desperate that they..".
Eehm..

>Some more about activating would-be tool developers: how about ...
>- stimulating (paying?) someone/some group to create a GCC for the
>12/14/16 bit cores?
>- releasing a free GCC for the 30Fs without the optimization but with
>the libraries?
>- bombarding Scott (or who someone else) with PIC samples untill he
>finishes SDCC?
>- bombarding some Jal-developers (not me) with 30F samples until Jal
>supports the 30F?

Maybe they have other (probably more important) things to think about?

>and of course, as said, open up the uChip tools for Linux....

Yes, there's a lot that can be done.. but if developers do not develop
because the FREE chips don't come "by surprise!" through a nice and
smiling blonde girl (or Santa Claus, for the matter), then I think
we've to blame not only uChip..

Or maybe you're used to be fondled by the big companies and I cannot
really understand you.. and maybe I'm being too practical and insensitive? ;)

I got this URL by simply searching for 'GCC'. The top item found is the
source. The original poster asked about 'libraries' being released too,
but I don't know which libraries they were referring to. So I don't know
if this release includes those libraries or not.

> <IMHO> Microchip is doing more than a lot with its samples
> program, and
> pretending that they even ring at your door unexpectly may look a tad
> excessive </IMHO>

I totally agree. But the OP's question was what uChip *could* do more,
in their own interest (especially to promote the 30F's to hobbyists). I
haven't even hinted that they *should* do any of the things I suggested!

> What would the competitors say? "Microchip is so desperate
> that they..". Eehm..

What would the competitors' stockholders say when said competitors are
driven from the hobby market? Todays hobby/educational market has a big
potential of being next decade's professional market...

> >- bombarding .....
> Maybe they have other (probably more important) things to think about?

I don't blame them if they decide to spend their time on something else.
Weeding out silicon bugs and datasheet bloopers (especially the ones
that are pointed out to them!) might be a good suggestion. But if they
(indirectly) want to know what they could do to promote the 30F in the
hobby domain, why should I not give the suggestions that I can think of?

> Or maybe you're used to be fondled by the big companies

I am not. I once got that PS+, and a few PIcs, and (equally unexpected)
some SX samples (that might have been Pavel Baranov's doing, they were
all sent to me but half of them seemed to be ment for him. and at that
time he happened to work 500m from were I worked! for those who do not
recognise that name: C2C etc.) I don't remember on who's initiative I
got the PIC stuff, but it certainly surprised me and at that time and
influenced how I spent my (hobby) time. With some results that certainly
did something for PICs in the hobby domain.

You seem to confuse my suggestions (which were asked for!) with demands.
Note that I don't require or even suggest they do all those nice things
to *me*. Part of the grunt work of such a program would be to select the
right target persons.

>> Years and years ago when I was developing WISP and the first
>> steps of Jal (I was still just a hobbyist then) I got a free
>> PS+ and some samples from uChip

> Wow, a free PS+, that was quite generous.

Hmm. I wonder whether whether Wouter has "moved up in the world"
and is expected (as an established vendor of PICs and PIC development
tools) to simply ask for development resources if he needs or wants
them? I know that the first time I ordered samples from microchip,
I very shortly received a phone call from cisco's microchip rep,
introducing herself and asking whether I needed any additional
help or resources, whether I needed the samples hand delivered
RIGHT NOW, and so on. I explained that my interest in PICs was
as a hobbyist rather than for a cisco project, and I think we have
a comfortable "understanding" these days, but it was an interesting
experience, and I'm pretty sure if I were to actually work on a
project involving a PIC I'd be able to get all sorts of free
development tools...

Now, Wouter isn't cisco, but then cisco isn't an "ambassador for
microchip" the way Wouter is either, and I would think that a word
in the right ear would get him dsPIC development tools aimed at
better support for them in WISP and/or JAL. Finding the right
ear might be a bit difficult, though (like, I wouldn't know how
to find cisco's microchip rep if she weren't on top of things...)

> 2) The examples are really, really spare. To make things worse, the
> dsPIC architecture is not nearly as simple as the 18f or 16f, with
> a DSP instructions and that really badly documented...

Heh. Doublethink. On the one hand we have assertions that the
DSP portions can be ignored, and on the other hand we have complaints
that a big problem is that the DSP portions are poorly documented
and don't have enough examples :-) (not that both can't be true.)

On another note. Got the August Circuit Cellar Inc yesterday. Big
intro about how there had been requests for projects updated to more
modern technology, including a plug for an article on a updated
project that used to be based on a PIC16C55. Yeah, I thought! Let's
see what THEY think about modern replacements for "classic" PICs.
And what PIC did they use to update this 16C55 project? Why, a
16C55A! ARRRRGGGGHHH! (running at twice the clock rate of the
original, but STILL frustrating!)

OK Scott, that's the minimum uChip is obliged to do to use the GCC code.
But my suggestion was that if they want to promote the 30F for
hobbyists, why not provide a real compiler (maybe minus the
closed-source optimizer) so I can point my students (who know C but not
much else) at an URL which they can install and have a go. For the
14-bit core I point them at the hi-tech demo and off they go.

> >> Years and years ago when I was developing WISP and the first
> >> steps of Jal (I was still just a hobbyist then) I got a free
> >> PS+ and some samples from uChip
>
> > Wow, a free PS+, that was quite generous.
>
> Hmm. I wonder whether whether Wouter has "moved up in the world"
> and is expected (as an established vendor of PICs and PIC development
> tools) to simply ask for development resources if he needs or wants
> them? I know that the first time I ordered samples from microchip,
> I very shortly received a phone call from cisco's microchip rep,
> introducing herself and asking whether I needed any additional
> help or resources, whether I needed the samples hand delivered
> RIGHT NOW, and so on. I explained that my interest in PICs was
> as a hobbyist rather than for a cisco project, and I think we have
> a comfortable "understanding" these days, but it was an interesting
> experience, and I'm pretty sure if I were to actually work on a
> project involving a PIC I'd be able to get all sorts of free
> development tools...
>
> Now, Wouter isn't cisco, but then cisco isn't an "ambassador for
> microchip" the way Wouter is either, and I would think that a word
> in the right ear would get him dsPIC development tools aimed at
> better support for them in WISP and/or JAL. Finding the right
> ear might be a bit difficult, though (like, I wouldn't know how
> to find cisco's microchip rep if she weren't on top of things...)
>
> BillW

Oops just realised the horrible typo. Haha it should be sparse not
spare.
Anyway, the DSP portion really can be ignored, I haven't touched it.
However what can't be ignored is the fact that the byte version of some
instruction don't have the same range operands as their word counter
parts. An example is skipping my mind right now alas.

> Hmm. I wonder whether whether Wouter has "moved up in the world"
> and is expected (as an established vendor of PICs and PIC development
> tools) to simply ask for development resources if he needs or wants
> them?

I have moved up in the sense that if I feel I need a development board I
just buy it. At this moment the phyiscal sapce it will take up will
probably be more of a problem than the price. If I don't use it I can
always put it in my shop, and if I do use it and I like it I can do the
same. But that moving up also means that I have zero hobby time to spend
on 'nice' projects like a Jal++.

> Now, Wouter isn't cisco, but then cisco isn't an "ambassador for
> microchip" the way Wouter is either, and I would think that a word
> in the right ear would get him dsPIC development tools aimed at
> better support for them in WISP and/or JAL.

No, no! I don't need that no more, I can buy my tools if I need them!

What I was suggesting was that

1- years ago, when I was a hobbyist with plenty of time (no kids, no
webshop, wife sometimes staying in the town were she worked) a lousy PS+
(lousy in uChip funds terms) made quite a difference. There are bound to
be compareable cases around at this moment. The grunt work is to
identify them.

2- even when I say I don't need free stuff any more just sending some
*might* still make a difference, but the return-on-investment is
probably much lower than in case 1. there might be different kinds of
bait that work much better in case 2, but that's for a shrink to find
out. or maybe it's in Raymond's book.

If I were uChip I would be much more worried about a collapse of the
piclist than about the future of Jal and/or Wisp. Not that I don't have
faith in our benevolent dictators, but at one time the burden might
become too high (either financially or emotionally, or maybe just the
hours).

On Thu, Aug 25, 2005 at 07:22:50PM +0800, Chen Xiao Fan wrote:
> > and of course, as said, open up the uChip tools for Linux....
> > Wouter van Ooijen
> This would be quite difficult due to their company policy and I
> think the support is not so easy and it requires lots of resources.

Correct. Linux isn't Mchip's fight. MChip helps out a lot by
releasing the programming specifications and the like.

It's a support issue. Why invest all those resources into supporting
a market segment that well less than 10 percent?

> Another thing is that the Linux PIC community are very quiet
> generally speaking. Just check out the GNUPIC list and you will know. :(

Quiet how? We generally just go about our business. Most of us do not
believe that Linux support is Mchip's problem. Also I notice in your
Mchip forum thread that there's an assembler and linker in the package
too. So dsPIC support in gputils all of a sudden isn't so critical.

4) Sponsor freelance programmer developers with a known good
PCIkit 2, PS+ or better a Promate III (ICSP built-in, no need extra
adapters).

5) Hand out samples and databooks to the selected people.

6) Provide APIs (maybe under NDA) for ICD2 and even ICE2000/4000 to
selected people and sponsor them to help those things talk to Linux
or alternative tools under Windows.

7) Please add your suggestions

As for the cost of ICD2, actually I have talked to the sales
engineer and he has an idea. He is soliciting Microchip to
allow low cost clones to be endorsed by Microchip and sell to
selected countries like Tailand and Indonesia. Maybe this
idea can be extended to other countries. Actually Microchip
is doing this in China. They allow two major distributors to
clone the ICD2 (square shape) and assist them to develop
cheap emulators. However to me the cost of these official
clones are still too high. Actually an ICD2 clone can be
built in China at quite low cost. A PICkit 2 clone can be
even cheaper.

However one thing is that as much as I like open source
software, I would still like to see third party software
companies like Hitech to survive. That is hard to do if Microchip
simple give out C18 or C30 for free. For example, if Microchip
gives out C30 totally free, dsPICC will be a hard sell. I think
dsPICC is already not selling well due to lack of interests in
dsPIC and the major customers are using C30.

I think you should be able to get it for free if you tell them
you will add dsPIC support to JAL and Wisp628. :) US$100 is
too much to pay. I think there will be people from Microchip
who will help you. I will ask my friend in Microchip Singapore
to try to help you.

Maybe I am the lucky type and we have very good support from
local Microchip even though we are not a big customer of them
(but we are one of their typical or unique ? customer). We have
the two dsPIC books (family manual and programmer's manual) even
we will never use them in our product.

On Thu, 2005-08-25 at 19:54 -0400, Byron A Jeff wrote:
> On Thu, Aug 25, 2005 at 07:22:50PM +0800, Chen Xiao Fan wrote:
>
> Another thing is that the Linux PIC community are very quiet
> > generally speaking. Just check out the GNUPIC list and you will know. :(
>
> Quiet how? We generally just go about our business. Most of us do not
> believe that Linux support is Mchip's problem. Also I notice in your
> Mchip forum thread that there's an assembler and linker in the package
> too. So dsPIC support in gputils all of a sudden isn't so critical.

As one of the Linux developers, I admit I'm quiet when it comes to public
discussions and probably should participate more. However, if I think
there is something to say then I'll probably say it - unless I'm too busy
coding. (gpsim's ChangeLog is probably larger than my GNUPIC posts!)
Besides, BAJ does an excellent job filling in the discussion void. But
please don't misconstrue mine or Craig's quietness as lack of interest.

On Thu, Aug 25, 2005 at 06:04:34PM -0700, Scott Dattalo wrote:
> On Thu, 2005-08-25 at 19:54 -0400, Byron A Jeff wrote:
> > On Thu, Aug 25, 2005 at 07:22:50PM +0800, Chen Xiao Fan wrote:
> >
> > Another thing is that the Linux PIC community are very quiet
> > > generally speaking. Just check out the GNUPIC list and you will know. :(
> >
> > Quiet how? We generally just go about our business. Most of us do not
> > believe that Linux support is Mchip's problem. Also I notice in your
> > Mchip forum thread that there's an assembler and linker in the package
> > too. So dsPIC support in gputils all of a sudden isn't so critical.
>
> As one of the Linux developers, I admit I'm quiet when it comes to public
> discussions and probably should participate more. However, if I think
> there is something to say then I'll probably say it - unless I'm too busy
> coding. (gpsim's ChangeLog is probably larger than my GNUPIC posts!)

> Besides, BAJ does an excellent job filling in the discussion void. But
> please don't misconstrue mine or Craig's quietness as lack of interest.

Discussion is all I had time for in all of these years. But times are
changing. I'll be back to active development very soon.

You are doing excellent jobs and I will not say that you are lack
of interests. I am also experimenting with Linux PIC development
and I know the progress is really fast on the gputils/gpsim/sdcc
front.

What I said is just my personal observations. My personal experience
in my failed PhD study mission in USA tells me a lesson to be
more outspoken and to communicate more. Microchip may not official
endorse Linux but there are people inside Microchip who wants to
help. Some of them are really very nice and are willing to go an
extra mile to extend their support.

I am a bit disappointed that nobody in the GNUPIC list answered
the post of James Grosbach. A post like that should be really
encouraged.

Maybe I talked too much about Linux. I should probably
replace "Linux community" with "open source community"
(Linux and Windows, MacOS and FreeBSD as well). The major
open source tools for PIC is indeed cross-platform.
gputils/gpsim/sdcc are working on both Linux and Windows.
Even people under Windows will like to use MPLAB but
lots of the Windows-only people would like to get a command
line version of ICD2 programming.

Maybe I should even extended to the free world ("free"
as in "free beer"). However I think Micorchip does support
lots of third-party ISVs.

> >> Ic-prog? Is it a programmer or just a software?
> >
> > it is just softwaree, but it suppports a wide range of (too) simple
> > hardware (the typical serial-port pin-wiggling proggers). Not my
> > recommended choice, but it is what a lot of starters use.
>
> There are a bunch in that class. If you look at ic-prog, winpic,
winpicprog
> and the like, probably 75-95% of all hobbyists at least started with that
> sort of approach. Today perhaps a USB programmer makes more sense, but if
> you want to penetrate the hobbyist market, then you need to be looking at
> the non-proprietary programmers, no matter how bad an idea you think that
> is.
>
> But if you (i.e. Microchip) take a disdainful attitude toward the "typical
> serial-port pin-wiggling proggers" then you are writing off virtually all
> the hobbyists, save the tiny few with understanding wives.

I build and sell "typical serial-port pin-wiggling proggers" programmers and
have made PICmicro popular with students and hobbyists along with ICD2
equivalent.

Due to the cost difference between the origanal and clones, the clones sell
more :-).

> When will be Wisp648 (or better Wisp2550) be out?
> When will the PICkit 2 clone be out?
> Warp? It is out of the business even though the
> author still supports it. Right?
> Pony-Prog? The author seems no longer support it.
> Ic-prog? Is it a programmer or just a software?

You have left out WINPIC800. This supports many dsPIC along with 10F, 12F,
16F and 18F. IT has many good features and very fast in programming compared
to ICPROG. Supports many hardware interfaces along with JDM :-).

Oh yes I remember I came across this in the Microchip
Forum USB section. Too bad I do not understand Spanish.

The GTP_USB and GTP_USB Lite seem to be quite nice
little USB programmers. Maybe it is the existing version of
Wouter's coming "Wisp2550". The user interface of WinPIC800
is also quite okay. It actually supports most 10F, 12F, 16F,
18F and dsPICs. Looks promising and I may want to try to
build one later. Now I want to concentrate on my PICKit 2.

> Maybe I am the lucky type and we have very good support from
> local Microchip even though we are not a big customer of them
> (but we are one of their typical or unique ? customer). We have
> the two dsPIC books (family manual and programmer's manual) even
> we will never use them in our product.

Likewise I have some 12F and 18F books, because at that time I did a lot
(a lot of orders, probably a neglectible total nr of PICs) of PIC
orderding via the local reseller. I switched to ByMicrochip (much
cheaper!) so I don't think it is ethical to bugger my reseller any more.
I could of course try the Microchip guy in my country.

Yet another suggestion:

Currently they don't allow datasheets to be reproduced on third-party
CDs or otherwise. For third-world, low-speed-connected hobbyists is
would be convenient to be allowed to distribute these on CDs, and for my
students I would like to have for instnace the 16F688 datasheet as
reader.

> Correct. Linux isn't Mchip's fight. MChip helps out a lot by
> releasing the programming specifications and the like.
>
> It's a support issue. Why invest all those resources into supporting
> a market segment that well less than 10 percent?

I don't say the would need to port their software to Linux, but they
could for instance release (and more or less freezing) the communication
interface of the ICD2.

> > I build and sell "typical serial-port pin-wiggling proggers"
> > programmers and have made PICmicro popular with .. hobbyists
>
> Is it theoretically possible to program a dsPIC with such
> a JPM-style programmer?

Why not. As long as PGD, PGC, and VPP can be controlled by the serial port,
PICmicro or dsPIC can be programmed.

> You have left out WINPIC800. This supports many dsPIC along
> with 10F, 12F,
> 16F and 18F. IT has many good features and very fast in
> programming compared
> to ICPROG. Supports many hardware interfaces along with JDM :-).

I think this is the one an Italian customer of me was so enthousiastic
about. I'll add it to start-with-pics. But could you convince the author
to put some english on his webpage?

Microchip has very nice comparison charts on their website. But the
DsPICs are in a chart of thier own, and the other PICs are split between
FLASH and ENHANCED FLASH. So someone who is looking for a 2-UART PIC
(that happens quite often, check pislist archive) has to look in three
different comparison charts (minor nuisance), and (bigger problem) he
has to be aware that there are three different charts!

Yet another suggestion: uChip could make sure that the PCB tools used by
newbies (Eagle, maybe some others?) have a decent (and up-to-date) PIC
library. Maybe it would be enough to pay Olin to get a copy of his libs
to start with, but the real issue is maintaining such a lib, and making
sure a newbie will find it.

> It is possible. However I still will prefer to use a
> PIC programmer with PICs inside. I've read too many
> problems with JDM type of programmers using all kinds
> of software.

Yes, there are too many problems. It will be working for a long time and for
no reason it will stop working. A perfectly working chip will get programmed
with PS+ but not with these types of programmers.

On Fri, Aug 26, 2005 at 08:47:04AM +0200, Wouter van Ooijen wrote:
> > Correct. Linux isn't Mchip's fight. MChip helps out a lot by
> > releasing the programming specifications and the like.
> >
> > It's a support issue. Why invest all those resources into supporting
> > a market segment that well less than 10 percent?
>
> I don't say the would need to port their software to Linux, but they
> could for instance release (and more or less freezing) the communication
> interface of the ICD2.

But does that not then open up an entire set of alternative software and
hardware for such products? There are already ICD2 clones right?

And it's still a support issue as I pointed out in my original post.
Something doesn't work with clone software and someone calls MChips for
support.

On Thu, Aug 25, 2005 at 10:37:04PM -0700, William Chops Westfield wrote:
>
> On Aug 25, 2005, at 9:37 PM, eCHIP wrote:
>
> >I build and sell "typical serial-port pin-wiggling proggers"
> >programmers and have made PICmicro popular with .. hobbyists
>
> Is it theoretically possible to program a dsPIC with such
> a JPM [sic] -style programmer?

Of course. The problem with JDM style programmers in today's climate
is that PC serial ports are so screwed up electrically. They don't
even try to conform to the RS-232 standard. Some have voltage swings
as little as 0 to 3.3.V.

A level converter and an outside high voltage source are a must for
any reliable serial port based programmer. In addition if you're
planning on using a USB to serial cable, you cannot make timing
guarantees between the modem control signals and the RX/TX signals.

> > I don't say the would need to port their software to Linux, but they
> > could for instance release (and more or less freezing) the
> communication
> > interface of the ICD2.
>
> But does that not then open up an entire set of alternative
> software and hardware for such products?
> There are already ICD2 clones right?

AFAIK the ICD2 clones use the uChip firmware (maybe with their own
bootloader), so they don't need to know the protocol. But someone
writing MPLAB-for-Linux would definitely need to know the protocol.

> And it's still a support issue as I pointed out in my original post.
> Something doesn't work with clone software and someone calls
> MChips for support.

uChip is not obligated to do anything but increasing shareholder value.
But this discussion is all about suggestions how they could do this.
Mind: suggestions. If I'd know all the answers I'd not be just VOTI.

> It is possible. However I still will prefer to use a
> PIC programmer with PICs inside. I've read too many
> problems with JDM type of programmers using all kinds
> of software.

You pick your poison. With a simple (no PIC inside) programmer you get
generic, widely available software from a variety of sources. If one
programmer gets bored with support, there are a dozen others.

With an onboard PIC, you get essentially one-man support unless you go the
long dollar approach from Microchip. As long as your provider continues to
support the parts you want to use and the operating systems you want to use,
all is well. But once your provider gets bored, it's time for a new
programmer.

Even with the MIcrochip apprach there are no guarantees. At some point they
will make a business decision to no longer support your device, whatever it
is. But at least you have some assurance that the latest devices will be
supported at least for a while.

Which approach is best for any individual depends not only on what they are
willing to spend, but how much hassle they are willing to put up with, and
how high their blood pressure will go when support ends. And that last part
is simply a guessing game. You just got to read the tea leaves and take
your best shot.

I have no problem with people choosing any programmers.
It is their choice. However I will still consider JDM
type as legacy just like 16F84. It is my observation
and I think lots of the people will agree with me. People
can start with JDM. However it is better to move to
something like Wisp628 later. Adding a external power
supply and a RS232 level converter will probably rescue
a JDM in some cases but then the price will not be so different
from Wisp628.

I do not agree with you that those programmers with PIC
inside have only only one-man support. Here I like open
source implementations like Wisp628. Even Wouter stops
supporting Wisp628 (unlikely now), the source code is
available and alternative software like Xwisp2 are actually
better. EasyProg from Olin is another example. Even though
there is only Olin's pc host software implementations now,
People have ported his EasyProg firmware to Wisp628 (EasyISP).
It is a pity that WinPIC800 is closed source but this is the
copyright owner's decision and they must have their reason
to do so.

Even those from Microchip are not necessary of high price.
And there are cheaper clones available. Again I like the
implementations with source code available like PICkit 1
and PICkit 2 (now only in the CD shipped though). Even Microchip
decide to stop supporting them, it can not stop people
continue supporting them and even extend the functionality
of them.

GNUPIC is a valuable resource. I just point out my observation.
Some people may think Linux support is not Microchip's business
and I agree it will not be their main focus. However there
is no harm asking for more support as well, right? There are
people inside Microchip who would like to support open source
community within their capacities.

S/N in PIClist is quite good as well if you only subscribe to
[PIC] and [EE]. As for S/N, I think AVR-GCC related
list are even better. However PIClist is still the best list
I subscribed so far. I sometimes read [OT] as well and there are
interesting posts as well.

Hmm. Another problem with attracting hobbyists to dsPIC is that it
is both too unique and too ordinary...

Too unique, we've been talking about. Not enough examples, few
existing projects, etc. But there's more. If one picks a 16F84
for their first project, they know that even if it isn't the best
possible choice, it is basically compatible with a LARGE range of
rather compatible microcontrollers. All the way from 6 to 40+ pins,
with a wide variety of packages, memory options, peripherals, and so
on, all within hobbyist budget and availability. One is confident
that even if it isn't the best choice, it IS a stepping stone to
those better choices...

Too ordinary... The problem here is that we have a relatively
uncommon 28pin $10 microcontroller. There are LOTS of those.
8051s, 6805s, 6808s, COP8s, ST6, Z8s, AVR, Cypress... Decide
on an 18pin package (for no particularly good reason), and the
choices are much more restricted... :-)

> Hmm. Another problem with attracting hobbyists to dsPIC is that it
> is both too unique and too ordinary . . . If one picks a 16F84
> for their first project, they know that even if it isn't the best
> possible choice, it is basically compatible with a LARGE range of
> rather compatible microcontrollers.

Probably depends on the motivation of the hobbyist. :-) If the
motivation is purely to use the dsPIC as a means to an end, and
preferably in the fastest, easiest way, then you are absolutely
correct. However, there are some of us (I am assuming that I am not the
only one, which may be an incorrect assumption) whose interest is in
exploring the potential of the PIC, rather than actually doing something
with it. For us, having a new, unique chip that no one has yet done
much with, and that there is not of lot of tutorial-type material
available on, is exciting. After all, the starship Enterprise didn't
go check out Chicago -- they went to new, unexplored places. :-)

On Sat, Aug 27, 2005 at 01:23:47PM +0800, Chen Xiao Fan wrote:
> I have no problem with people choosing any programmers.
> It is their choice. However I will still consider JDM
> type as legacy just like 16F84. It is my observation
> and I think lots of the people will agree with me. People
> can start with JDM. However it is better to move to
> something like Wisp628 later. Adding a external power
> supply and a RS232 level converter will probably rescue
> a JDM in some cases but then the price will not be so different
> from Wisp628.

Xiaofan,

You keep espousing that argument, but I never see a real
justification as to why. Wouter has pointed out that cost
effective programmers have their place because they are
cost effective. The bootloader approach I discuss pretty
much demands an inexpensive programmer. Truthfully even
a homebuilt Wisp628 needs a cheap, easy to build programmer.

> I do not agree with you that those programmers with PIC
> inside have only only one-man support. Here I like open
> source implementations like Wisp628. Even Wouter stops
> supporting Wisp628 (unlikely now), the source code is
> available and alternative software like Xwisp2 are actually
> better. EasyProg from Olin is another example. Even though
> there is only Olin's pc host software implementations now,
> People have ported his EasyProg firmware to Wisp628 (EasyISP).
> It is a pity that WinPIC800 is closed source but this is the
> copyright owner's decision and they must have their reason
> to do so.

Now IIRC you've posted bootloaders (Chia I believe for the
dsPIC). Now if you have a BCD and a bootloader, then exactly
what does any of the three above bring to the table?

I finally figured out that many believe that a programmer is
an important tool in the development process because they use
the programmer in the development process. Since I don't
use the programmer in the development process, its functionality
or reliability isn't of much relevance. When a programmer
becomes a BCD, the overriding factors become cost and ease of
construction. That's why the one chip, handful of resistors and
transistor approach of the Trivial programmers are important.
They become cheap and asy to build for BCD use.

By the way I'll answer the bring to the table question above.
The answer is that unfortunately Mchip has not seen fit to make
their entire line self programmable. Personally I find it
aggravating that parts like the 12F629 and 12F675 cannot be
configured in bootloader configurations. That means for ICSP
development that half your pins are being used as the interface
for programming durin development.

My interim solution to such problems is something along the
lines of my PicDesigner project, which is a fully outfitted
development box. Of course it has a bootloader interface so
programming it is as simple as plugging it into a serial port.
An obvious upgrade now would be to use a USB enabled 18F PIC
and provide a USB interface. But in effect you use the big box
as a bootloaded emulator, then when the project is finished
use a BCD to dump the code into a smaller part for the final
target.

> Even those from Microchip are not necessary of high price.
> And there are cheaper clones available.

For a project or three, $30-$50 USD is expensive tooling for
hobby use. As Wouter keeps pointing out, there are folks who
are interested who have time >>> money. Students and tinkerers
who can live with buying a couple of 555s and some discretes.

It's one of the reasons that I'm sure that there is a bootloader
market out there. When you get the PIC, you get the programmer
too. It's just like getting a WISP628 without any of the
associated board parts.

On Sat, Aug 27, 2005 at 01:34:28PM +0800, Chen Xiao Fan wrote:
> GNUPIC is a valuable resource. I just point out my observation.
> Some people may think Linux support is not Microchip's business
> and I agree it will not be their main focus. However there
> is no harm asking for more support as well, right?
> There are
> people inside Microchip who would like to support open source
> community within their capacities.

Support in what way? MPLAB is the flagship product. gputils
already has most of its functionality. PicKits are supported
with firmware and interface support. Programming specifications
are available. They built the C30 compiler with GCC and have
honored the GPL.

As a longtime Linux user and developer, I can attest that MChip
has been infinitely more open about their developement tools and
documentation than many others.

So I'm just trying to figure out what you think we need to ask
of them? They've already done pretty much everything that a
Linux community member would want, except for maybe an Open Source
release of their libraries for the C30 dsPIC compiler. But
then I'd ask what is it that's in the C30 libraries that hasn't
in some form been duplicated in the SDCC or other Open Source
C libraries? Do we really need a printf or scanf from Mchip?

I asking in all honesty. I think that Linux folks have gotten
used to being self supporting and in fact understand that it's
unreasonable to ask for the same level of development that
Windows folks enjoy. The key is to have a company that doesn't
inhibit Open Source development by withholding critical
information about a product or process. I have yet to see one
instance where MChip has done that. Have you?

> The key is to have a company that doesn't
> inhibit Open Source development by withholding critical
> information about a product or process. I have yet to see one
> instance where MChip has done that. Have you?

I am not stating that uChip is doing too little, or doing bad compared
to others. I wouldn't know what to base such a verdict on.

This thread started with a request for suggestions for how uChip could
do better, compared to what they do now. Just that: suggestions. It
is/would be up to uChip to evaluate such suggestions (as undoubtedly
they evaluate their own ideas) on cost/yield, or whatever other criteria
they want to use.

> When a programmer
> becomes a BCD, the overriding factors become cost and ease of
> construction.

Add: ease of getting it working.

I think a lot of time>>>money beginners do start with such a simple
programmer, some of it get it to work, but I am afraid some never get it
to work and drop the whole PIC idea. I have no idea of the relative size
of the two groups. So yes, almost-zero-cost programmers are important
for beginners (some might never start with PICs if it were not for these
type of programmers), but I am afraise there are also beginners who
maybe could have afforded a low-end intelligent programmer, but instead
try an almost-ene-cost one, can't get it to work, and drop PICs
altogether.

> That means for ICSP
> development that half your pins are being used as the interface
> for programming durin development.

in most cases that is not needed, a little thinking can find a use for
the ICSP pins. Or use a 14-pin chip as developer for an 8-pin chip. Or
the uChip 'extra-pins' version of the chip.

> Anyway I wrap up with my tagline:
> "PIC Programmers are overrated."

For a specific audience that might be true. But the question is of
course how big and/or relevant that audience is.

I think the most important thing is to open
up the MPLAB ICD2 protocol (programming and debugging).
That is the single most important hindrant for dsPIC
development under Linux.

To provide C30 buidling insturction (without the
close source optimizer) and packages will be another
good thing to do. To offer financial support to key
developers are also quite nice but I understand
that some of the developers may not want this kind of
support.

I think there are other things they can do better. I am
very satisfied with Microchip's support for my
projects in my work and I am not saying that Microchip
is doing quite badly in supporting the open source
community. As you said, they are quite good. I am
very new to PIC development on Linux (my first two posts to
GNUPIC mailing list are about LPLAB testing on Linux
and MPLAB under Linux with Wine on May 26, 2005) and
I think I've already have a working enviroment under Linux
similar to Windows with gputils/gpsim/sdcc/C18/C30.
That is quite good. However as Wouter and others have
said, Microchip can do better to foster the support of
dsPICs (including dsPIC development on Linux).

I still do not have my ICD2 working under Linux even
though PICkit 1 is working and hopefully PICkit 2 will
soon work under Linux as well.

Of course I am only a part-time Linux guy and I can always
boot back into Windows to have my ICD2 working if I mess up
my PICkit 2 and needs to reflash the flash. However there are
people who do not have Windows.

Even if there are cheaper programmers which support dsPICs on
Linux and if people can extend the bootloader by Daniel Chia and
the Tiny Bootloader, still the debugging will be an issue.
So open up the ICD2 protocol will one thing they can help
a lot. That is kind of critical info, right?
They can always keep the protocol/API close for the expensive
ICE2000/ICE4000. :)

> You keep espousing that argument, but I never see a real
> justification as to why. Wouter has pointed out that cost
> effective programmers have their place because they are
> cost effective. The bootloader approach I discuss pretty
> much demands an inexpensive programmer. Truthfully even
> a homebuilt Wisp628 needs a cheap, easy to build programmer.

Once the hobbyist has become serious enough to decide on a more complex
programmer, the ICD2 starts to look like a very real choice. Sure, it's
pricey compared to a Wisp, but you get a debugger, the ability to program
30F's, and -you- don't need to bootloader loader.

> Now IIRC you've posted bootloaders (Chia I believe for the
> dsPIC). Now if you have a BCD and a bootloader, then exactly
> what does any of the three above bring to the table?

I still haven't really seen the reason for a bootloader

> By the way I'll answer the bring to the table question above.
> The answer is that unfortunately Mchip has not seen fit to make
> their entire line self programmable. Personally I find it
> aggravating that parts like the 12F629 and 12F675 cannot be
> configured in bootloader configurations. That means for ICSP
> development that half your pins are being used as the interface
> for programming durin development.

Only for debugging. It's pretty rare that you don't have the flexibility to
lightly load PGD/PGC. OK, on a few chips you can use !MCLR as an output if
you don't need ICSP, but that's pretty unusual. On the dsPIC, you even have
multiple choices of pins to use for debugging.

> For a project or three, $30-$50 USD is expensive tooling for
> hobby use. As Wouter keeps pointing out, there are folks who
> are interested who have time >>> money. Students and tinkerers
> who can live with buying a couple of 555s and some discretes.

Now that is an important point. For the hobbyist starting out, the
programmer is generally considered to be for ONE project. Even $10 worth of
parts is a barrier. Once a hobbyist becomes geeked enough the $50 programmer
isn't so bad. The ICD2 is still a barrier, depending on one's spouse. My
ICD2 came for Father's Day <g>

I'm still thinking that an ICD2 clone might be a good choice for many
hobbyists.

Unfortunately, the Mchip docs on what the ICD2 will and won't do are not
easy to fathom until you have your hands on one. I think that is a big
barrier to hobbyists, who might consider a $150 debugger, but are afraid
that every new chip they try is going to take an expensive adapter. That
isn't the case, but if you look at the Microchip docs and the DigiKey
catalog you are lead to suspect that it is. You do need to be a little
cautious. Some chips need an adapter for debugging, but for a hobbyist,
there is always an alternative that doesn't.

On Sat, Aug 27, 2005 at 03:50:20PM +0200, Wouter van Ooijen wrote:
> > When a programmer
> > becomes a BCD, the overriding factors become cost and ease of
> > construction.
>
> Add: ease of getting it working.
>
>
> I think a lot of time>>>money beginners do start with such a simple
> programmer, some of it get it to work, but I am afraid some never get it
> to work and drop the whole PIC idea.

That's why I debate the utility of programmers in general. My holy grail
for this segment is the PIC programmer equivalent of a Knoppix style
Live CD. You just pop it in and it just works.

> I have no idea of the relative size
> of the two groups. So yes, almost-zero-cost programmers are important
> for beginners (some might never start with PICs if it were not for these
> type of programmers), but I am afraise there are also beginners who
> maybe could have afforded a low-end intelligent programmer, but instead
> try an almost-ene-cost one, can't get it to work, and drop PICs
> altogether.

I'm with you there. The fact is that the pogrammer gets in the way of
a hobbyist getting started. It's one of the reasons that items such
as the Basic Stamp and the PicAxe have a following. Both of course
couple an HLL on top. I still debate the necessity of that.

The reason this is such a stick subject is that there are so so so many
variables. Just off the top of my head (in no particular order):

Cost
Reliability
Support
Culture (folks use programmers because every document says to need a programmer)
Interfaces (We need a solution to the USB problem)
Ease of Implementation

With so many vectors, I know that one solution will not satisfy everyone. However
I do think we need to give thought and discussion to appropriate options.

USB is a sticky subject. I've been thinking how far into the learning curve
would one get before implementing USB for the application becomes important?
It's one of those places where the programmer vs. bootloader debate becomes
murky. Is it possible or appropriate for the bootloader and the application
to share the USB interface? Mostly because of your thoughts on the subject,
I have grave issues about the transparancy problem there.

No answers yet, just questions.

>
> > That means for ICSP
> > development that half your pins are being used as the interface
> > for programming durin development.
>
> in most cases that is not needed, a little thinking can find a use for
> the ICSP pins. Or use a 14-pin chip as developer for an 8-pin chip. Or
> the uChip 'extra-pins' version of the chip.

So my proposed solution is along those same lines. I've built most of my projects
with 40 pin targets. Size wasn't a real concern.

>
> > Anyway I wrap up with my tagline:
> > "PIC Programmers are overrated."
>
> For a specific audience that might be true. But the question is of
> course how big and/or relevant that audience is.

Like everything else Wouter, statements are never considered until they
are made.

On Sat, Aug 27, 2005 at 03:50:20PM +0200, Wouter van Ooijen wrote:
> > The key is to have a company that doesn't
> > inhibit Open Source development by withholding critical
> > information about a product or process. I have yet to see one
> > instance where MChip has done that. Have you?
>
> interfaces!
> - MLAB <-> ICD2 interface (RS232/USB)
> - MLAB <-> third party programmer software

Ah! I see. Both of those are Windows specific AFAICT. So they
are outside of my scope.

Would the MPLAB to ICD2 interface help in developing ICD2
host software for Linux?

>
> I am not stating that uChip is doing too little, or doing bad compared
> to others. I wouldn't know what to base such a verdict on.
>
> This thread started with a request for suggestions for how uChip could
> do better, compared to what they do now. Just that: suggestions. It
> is/would be up to uChip to evaluate such suggestions (as undoubtedly
> they evaluate their own ideas) on cost/yield, or whatever other criteria
> they want to use.

Of course. I'd be interested to see if MChip thought there was any
benefit in having an MPLAB benefit to 3rd party programmers. As I've
stated earlier, I'd be leery of that if I were them. Because as soon
as some 3rd party programmer doesn't work with MPLAB, customers will
be ringing up or E-mailing MCHIP to ask why it doesn't work. If I were
Mchip, that certainly wouldn't be a beneficial thing, considering that
MPLAB isn't a direct profit center for them.

> Would the MPLAB to ICD2 interface help in developing ICD2
> host software for Linux?

of course!

> Because as soon
> as some 3rd party programmer doesn't work with MPLAB, customers will
> be ringing up or E-mailing MCHIP to ask why it doesn't work. If I were
> Mchip, that certainly wouldn't be a beneficial thing, considering that
> MPLAB isn't a direct profit center for them.

They did open up the interface to 3d party compilers, which could cause
them the same problem.

On Sat, Aug 27, 2005 at 09:58:21PM +0800, Chen Xiao Fan wrote:
> I think the most important thing is to open
> up the MPLAB ICD2 protocol (programming and debugging).
> That is the single most important hindrant for dsPIC
> development under Linux.

Why? There are already software and programmers and bootloaders
for developing the dsPIC on Linux. Obviously as a 100% Linux
user, the ICD2 is completely out of my scope. So if you have
a minute, explain what does it bring to the table.

>
> To provide C30 buidling insturction (without the
> close source optimizer) and packages will be another
> good thing to do.

That's been done by someone else. You've posted the links
to it. MChip has been very very gracious in sticking to the
GPL and releasing the source for C30. The Linux community
doesn't need them to be the developer for that community.

> To offer financial support to key
> developers are also quite nice but I understand
> that some of the developers may not want this kind of
> support.

What's the benefit to MChip to add money to the situation?
There simply isn't enough of a customer base to justfy
spending any money.

Frankly it's a foolish endeavor to invest money with no
apparent ROI to developers who would in fact do it for free.

With C30, quid pro quo has already happened. MChip didn't
have to start building a compiler/assembler from scratch.
The community gets the benefit of the changes and additions
to the base that MChip started from.

>
> I think there are other things they can do better. I am
> very satisfied with Microchip's support for my
> projects in my work and I am not saying that Microchip
> is doing quite badly in supporting the open source
> community. As you said, they are quite good. I am
> very new to PIC development on Linux (my first two posts to
> GNUPIC mailing list are about LPLAB testing on Linux
> and MPLAB under Linux with Wine on May 26, 2005) and
> I think I've already have a working enviroment under Linux
> similar to Windows with gputils/gpsim/sdcc/C18/C30.
> That is quite good.

Bingo. After fighting battles with other companies simply
to get enough information to do implementation, MChip is
quite a refreshing change.

> However as Wouter and others have
> said, Microchip can do better to foster the support of
> dsPICs (including dsPIC development on Linux).

They have. You can do dsPIC development on Linux. It
may be nice if they released a subset of the dsPIC library
under an Open Source license. But there are already free
C libraries out there. Why can't they be adapted to the
C30 compiler?

>From a business perspective, MChip gains little from supporting
Linux in any substative way. They should continue doing what
they have been doing up until now: plant cheap seeds that have
little development and support cost, and see what pops up.

> I still do not have my ICD2 working under Linux even
> though PICkit 1 is working and hopefully PICkit 2 will
> soon work under Linux as well.

Interface specs would be nice. But as I pointed out before,
MChip opens themselves up to support headaches whenever they
release an interface spec for their product. In addition to
cloning, they then have to deal with issues when some 3rd
party software causes a problem with their ICD2. The other
issue is that whenever you Open Source release, the code has
to be reasonably clean.

I'm not sure how to resolve it. Why not ask them for an
interface specification for the ICD2 and see what they say?

> Of course I am only a part-time Linux guy and I can always
> boot back into Windows to have my ICD2 working if I mess up
> my PICkit 2 and needs to reflash the flash. However there are
> people who do not have Windows.

Like me. Of course I don't have an ICD2 either. I have a tough
time justifying plunking down $160 when a Tait style programmer,
some existing software, and the potential for bootloading are
all already on the table. MChip has already contributed greatly
because they put free dsPIC samples in my hands.

> Even if there are cheaper programmers which support dsPICs on
> Linux and if people can extend the bootloader by Daniel Chia and
> the Tiny Bootloader, still the debugging will be an issue.

Xiaofan, I've been in the embedded systems game for close to
20 years now. While hardware level debugging is certainly
convenient, it's not a required tool for successful development.

> So open up the ICD2 protocol will one thing they can help
> a lot. That is kind of critical info, right?

Debateable.

> They can always keep the protocol/API close for the expensive
> ICE2000/ICE4000. :)

I'm playing devil's advocate for Microchip. They have a complete
environment that the ICD2 works in. I see no benefit to them
to open the interface spec up. Can you name one?

On Sat, Aug 27, 2005 at 05:19:56PM +0200, Wouter van Ooijen wrote:
> > Would the MPLAB to ICD2 interface help in developing ICD2
> > host software for Linux?
>
> of course!
>
> > Because as soon
> > as some 3rd party programmer doesn't work with MPLAB, customers will
> > be ringing up or E-mailing MCHIP to ask why it doesn't work. If I were
> > Mchip, that certainly wouldn't be a beneficial thing, considering that
> > MPLAB isn't a direct profit center for them.
>
> They did open up the interface to 3d party compilers, which could cause
> them the same problem.

But MChip doesn't make money on software (C30 excluded). However I'm sure
they are profiting from PicKit and ICD sales. I'm actually surprised that
they allow for an ICD clone market at all.

So releasing the interface spec becomes a dual edged sword. While it
will benefit Linux, won't it further erode the ICD2 market share?

The ICD2 interface is one of the most important thing
to foster support for dsPIC and higher end 18F (like 18FUSB).
Both the programmer interface and debug interface are
important. AVR has a very good following in the hobbyists
community because of the cross-platform support of programmers
and debuggers. As much as I do not like to use AVR in my
work, I do envy that they have so good support for hobbyists
and open source community. Microchip is doing much better
in the business front than Atmel. They can do better in
the hobbyist front as well and I think they are willing to
do it as well because they listen to all kinds of customers
including students who will be the future business customers.
For example, Microchip Singapore allows some universities and
polytechnic institutes to build their own ICD/ICD2/Pickit and
provide training for them.

The developer of LPLAB has to use reverse-engineering method
to get some information of ICD2 programmer interface. If the
API/protocol is known, maybe he already come out a working
versions. It is for both Linux and Windows.

Microchip is allowing third-party compilers to be plugged into
MPALB. Actually there is a plugin for gputils as well. However
it is a beta. To allow for third-party plugin for programmers
will not be a problem for Microchip does not distribute
the plugins. The users are installing the plugins from third
parties like HiTech (PICC). So third-party developers should
take care of their plugins. However Microchip should open
the APIs.

MPLAB is one of the driving force for Microchip's success. From
MPLAB 4 to MPLAB 5 to MPLAB 6/7 and you see Microchip jumps to No 1
position in 8-bit MCU market and their market capital now is
about 6.46 Billion, 7 times of Atmel which has a much higher revenue
than Microchip.

> Why? There are already software and programmers and bootloaders
> for developing the dsPIC on Linux. Obviously as a 100% Linux
> user, the ICD2 is completely out of my scope. So if you have
> a minute, explain what does it bring to the table.

debugger!

> > To provide C30 buidling insturction (without the
> > close source optimizer) and packages will be another
> > good thing to do.
>
> That's been done by someone else. You've posted the links
> to it. MChip has been very very gracious in sticking to the
> GPL and releasing the source for C30.

No grace in that at all: if they use something that is GPLed they must
follow the rules! It would be a violation of the copyright law if they
did not.

Rather, they followed the letter (relased the modified source of the
part they used) but violated the spirit (they made a product, of which a
modified GCC is a part, and carefully separated the GPL-ed part from a
closed-source part).

> So releasing the interface spec becomes a dual edged sword. While it
> will benefit Linux, won't it further erode the ICD2 market share?

To the contrary. The ICD2 clone builders don't need the interface at
all, the only need the bootloader interface, which seems to be well
known. They ship the clone with the bootloader, and MPLAB downloads the
real debugger firmware. You of all people will appreciate this scheme :)
Having the ICD2 debugger interface available would enable alternate PC
software (Linux or otherwise), which can only increase the demand for
ICD2s (original or clone).

Microchip does not want to earn too much money on ICD2 and PICkit
1 or PICkit 2 either. Their core business is to sell chips to as many
customers as possible, big and small. Trust me, BAJ, even though
I have only 5 years of experience with PICs (3.5 years actually
since I need to minus my 1.5 years in USA). I think we need to
agree on this.

They allow a clone ICD2 market just because they want to sell more
chips. In China, they allow two major distributors to build
ICD2 (both are rectangular shapes even though you may
not understand Chinese). They are also both authorised by Microchip
build PS+ clones.
www.goldenchip.com.cn/tools/mplabicd2/mplabicd2.asphttp://www.burnon.com/product/development/index.asp

By the way, they do earn money on software like MPLAB C18 and MPLAB
C30 and some other dsPIC libraries. They can not simply give
them away. It will irk third party ISVs like Hitech and IAR and
CCS.

Okay it is 12:05am Sunday here in Singapore and I need to go to
bed. Luckily my wife is still watching TV by Jet Li. :)

Anyway, Wouter answered the question: debugger!!!

BAJ: I am not so sure whether you have used any higher
end MCU (than 12F/16F) like dsPIC or 18F USB. I am very
new to them as well and I think a debugger will be quite
useful.

I confess I am a lousy programmer so I need hardware
debugging provided by ICD2. I was using an ICE2000 for
my previous PICC projects on 16C72A/16F872 back in the
year of 2000 to 2002. The real-time debugging helps a
lot even the code is less than 2k words. People can use
printf to serail port or other methods to help the debugging
but sometimes the resource inside the MCU may not allow this.
Of course an ICE2000 is beyond the reach of a hobbyists.
Clone ICD2 may be the ways to go for hobbyists who want to
climb the hill of highed end 18F/PIC24/dsPIC30/dsPIC33.

For the AVR community, they have the excellent AVR-GCC,
AVRdud and JTAG debuggers. For developers of ARM, GCC and
JTAG are there as well. Hopefully there will be JTAG or
similar tools for the next generation of dsPICs/PIC24s.

On Sat, Aug 27, 2005 at 05:50:21PM +0200, Wouter van Ooijen wrote:
> > So releasing the interface spec becomes a dual edged sword. While it
> > will benefit Linux, won't it further erode the ICD2 market share?
>
> To the contrary. The ICD2 clone builders don't need the interface at
> all, the only need the bootloader interface, which seems to be well
> known. They ship the clone with the bootloader, and MPLAB downloads the
> real debugger firmware. You of all people will appreciate this scheme :)
> Having the ICD2 debugger interface available would enable alternate PC
> software (Linux or otherwise), which can only increase the demand for
> ICD2s (original or clone).

OK. I didn't know how the interface worked. So the clone literally
fools MPLAB into loading the firmware!

So now I'm with you. Has anyone asked MChip as to why the interface is
closed?

On Sat, Aug 27, 2005 at 11:35:01PM +0800, Chen Xiao Fan wrote:
> The ICD2 interface is one of the most important thing
> to foster support for dsPIC and higher end 18F (like 18FUSB).

In your opinion. Linux folks are probably not going to be
inclined to plunk down that type of money for an ICD2 unless
there's a big benefit coming back for it.

> Both the programmer interface and debug interface are
> important. AVR has a very good following in the hobbyists
> community because of the cross-platform support of programmers
> and debuggers. As much as I do not like to use AVR in my
> work, I do envy that they have so good support for hobbyists
> and open source community.

I can guess as to why you don't use the AVR. No guarantee of
getting chips in any reasonable timeframe right?

MChip certainly has it right for the hobby market. And with
their sample program, it's really on the ball.

> Microchip is doing much better
> in the business front than Atmel. They can do better in
> the hobbyist front as well and I think they are willing to
> do it as well because they listen to all kinds of customers
> including students who will be the future business customers.
> For example, Microchip Singapore allows some universities and
> polytechnic institutes to build their own ICD/ICD2/Pickit and
> provide training for them.

Well that's cool. This isn't an ICD issue AFAICT now. The real
issue is the fact that the only interface for ICD2 is embedded
in MPLAB.

But really right now to many of us on the outside looking in
it looks analogous to driving a Ferrari: You simply cannot
truly understand until you've done it.

Also I think that you overestimate the willingness of folks
to invest that much cash for hobby stuff. That's the sole
reason that low end Tait/JDM style programmers and their
associated software continue to proliferate. You and I have
gone back and forth over a $50 USD PicKit 2. A $160 ICD2
is light years away from that in cost.

I'm trying to get you to understand that for someone walking into this
development environment, that kind of money is a barrier to entry. I believe
it was you that stated something along the lines that you have a $60
allowance with the wife for tech tools. We've all been there. But like the
Ferrari, if you have not yet experienced the benefits of having PIC available
an investment on a tool like ICD2 is really out there. Typically upon entry
to a hobby (and BTW I'm strictly on the hobby perspective, pros need not
bother with this) it's important to get early success at a very reasonable
price. Lack of success or large investment will drive potential entrants
away. Now once they are in and having some success, then you can attempt to
convince them that better (and more expensive) tools would be of benefit to
them.

But frankly at this point you haven't convinced me, and I actually
understand the benefits of ICD.

> The developer of LPLAB has to use reverse-engineering method
> to get some information of ICD2 programmer interface. If the
> API/protocol is known, maybe he already come out a working
> versions. It is for both Linux and Windows.

I'm not arguing that point. Primarily I see a "We need this thing."
without supporting evidence of why it's needed.

This is just moot court anyway. Just sparring practice. At the end of the day
few hobbyists really need anything that dsPICs have to offer anyway. 2
hardware USARTS in a 28 pin package are probably the more interesting item.
USB is probably the only substative item that the 18F family brings to the
table. We still struggle trying to get new users to understand why they
shouldn't start with 16F84s.

>
> Microchip is allowing third-party compilers to be plugged into
> MPALB. Actually there is a plugin for gputils as well. However
> it is a beta. To allow for third-party plugin for programmers
> will not be a problem for Microchip does not distribute
> the plugins. The users are installing the plugins from third
> parties like HiTech (PICC). So third-party developers should
> take care of their plugins. However Microchip should open
> the APIs.

Wouter pointed that out. So what exactly is MChips response to requests for
interface information for the ICD2?

>
> MPLAB is one of the driving force for Microchip's success. From
> MPLAB 4 to MPLAB 5 to MPLAB 6/7 and you see Microchip jumps to No 1
> position in 8-bit MCU market and their market capital now is
> about 6.46 Billion, 7 times of Atmel which has a much higher revenue
> than Microchip.

And it points to why the relevance is so little to the Linux community.
Any serious Linux PIC developer hasn't used MPLAB since it was a 16 bit
DOS application. It's just not on our radar. Completely unimportant. So
its interfaces are of little direct use. We'd end up having to re-engineer
applications (like LPLAB) for it anyway.

I leave this part of the discussion with a situation:

"I'm a novice user that wants to build a circuit that keeps my lamp on
for one minute after I ask it to turn off. Folks like Xiaofan are
recommending that I purchase a $50 PicKit 2 or a $160 ICD2 (or a cheaper
clone) to do my development. But I see all of these inexpensive PIC
programmers out there. Why should I choose to invest so much for just
one simple project?"

On Sat, Aug 27, 2005 at 05:50:21PM +0200, Wouter van Ooijen wrote:
> > Why? There are already software and programmers and bootloaders
> > for developing the dsPIC on Linux. Obviously as a 100% Linux
> > user, the ICD2 is completely out of my scope. So if you have
> > a minute, explain what does it bring to the table.
>
> debugger!

As a gdb user I can appreciate a debugger to a point. I find that
simulators help with gross errors. But as a "love what you learn"
question, what does the debugger bring to the table that's outside
of the scope of "normal" debugging activities using I/O devices
such as serial interfaces and LCDs?

>
> > > To provide C30 buidling insturction (without the
> > > close source optimizer) and packages will be another
> > > good thing to do.
> >
> > That's been done by someone else. You've posted the links
> > to it. MChip has been very very gracious in sticking to the
> > GPL and releasing the source for C30.
>
> No grace in that at all: if they use something that is GPLed they must
> follow the rules! It would be a violation of the copyright law if they
> did not.

True. But with so many entities being unscrupulous about following even
the letter of the law, it's still a good thing to see.

>
> Rather, they followed the letter (relased the modified source of the
> part they used) but violated the spirit (they made a product, of which a
> modified GCC is a part, and carefully separated the GPL-ed part from a
> closed-source part).
>

Perfectly within their rights. You're talking about the optimizer then right?
If they wrote the optimizer from scratch as a value add, and that optimizer
is a separate entity from the compiler (which it clearly is), then more power
to them.

On 8/27/05, Byron A Jeff <byronSTOPspamspam_OUTcc.gatech.edu> wrote:
> "I'm a novice user that wants to build a circuit that keeps my lamp on
> for one minute after I ask it to turn off. Folks like Xiaofan are
> recommending that I purchase a $50 PicKit 2 or a $160 ICD2 (or a cheaper
> clone) to do my development. But I see all of these inexpensive PIC
> programmers out there. Why should I choose to invest so much for just
> one simple project?"

One small correction.

The Pickit2 is $35 if you only buy the programmer. Well,
buy.microchip.com charges $10 for shipping, but you can also buy it
from DigiKey once they get some in stock.

As far as the debate you guys are having, it's interesting. To me,
the pickit2 is a pretty cool prototype device in its own right. The
bootloader's already installed, and USB hardware/power supply, and it
comes with some example source code. Who says you must use it as a
programmer?

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie

On Sun, Aug 28, 2005 at 12:13:27AM +0800, Chen Xiao Fan wrote:
> Okay it is 12:05am Sunday here in Singapore and I need to go to
> bed. Luckily my wife is still watching TV by Jet Li. :)

Well then have at it in the morning.

> Anyway, Wouter answered the question: debugger!!!
>
> BAJ: I am not so sure whether you have used any higher
> end MCU (than 12F/16F) like dsPIC or 18F USB. I am very
> new to them as well and I think a debugger will be quite
> useful.

I have these parts sitting on my shelf waiting for me to get
to them. I want to rebuild my infrastructure before getting
back to project work. So tools such as a solid transportable
bootloader, stabilizing NPCI stable and regression tested,
and finishing work on my 555 based serial code dumper are
higher priority items on my PICList.

> I confess I am a lousy programmer so I need hardware
> debugging provided by ICD2. I was using an ICE2000 for
> my previous PICC projects on 16C72A/16F872 back in the
> year of 2000 to 2002. The real-time debugging helps a
> lot even the code is less than 2k words. People can use
> printf to serail port or other methods to help the debugging
> but sometimes the resource inside the MCU may not allow this.

So it's a style issue. See to me there is minimal interface
difference between a simulator and ICD. Primarily the fact
that it takes more work to get real input into the simulator.

I do gross debugging using gpsim. It sorts out the vast majority of
logic/thought errors will before I ever get around to putting code
into an actual chip.

As for printf being resource intensive, a bit banged routine takes
about 30 words to implement. That's cost effective for even the
smallest chips. You can see a sample of this in my sunrise/sunset
light controller here:

> Wouter has pointed out that cost effective programmers have
> their place because they are cost effective.

Things like the JDM programmer are beyond "cost effective" and
into the realm of "free tools" that we were just saying were
so important. Tools are tools; I'm not sure why a hobbyist
who isn't willing to pay $100 for a compiler would be willing
to spend $100 for a device programmer...

Byron A Jeff wrote:
> As a gdb user I can appreciate a debugger to a point. I find that
> simulators help with gross errors. But as a "love what you learn"
> question, what does the debugger bring to the table that's outside
> of the scope of "normal" debugging activities using I/O devices
> such as serial interfaces and LCDs?

I'm amazed you're even asking this, Byron. The big everwhelming advantage
is that you can single step your code, set break points, and look around at
state without having to decide up front which limited state you are going to
spit out at which limited set of circumstances. Other advantages:

2 - You don't have to write the code to send trace information somewhere,
nor the code to either format it nicely in the PIC, or receive it with a
special program which formats it for you to see.

3 - Just the existance of trace code can alter the problem you are trying to
find. Other code may be moved around, the timing will be different, stack
usage will be different, etc. Sometimes this will make the original symptom
disappear, and sometimes it can introduce symptoms that are only due to the
trace code in the first place.

4 - Trace code can require hardware resources that are already all in use,
like extra pins, UART, etc.

In short, debugging with a real debugger (ICE even better) is waaaaaay more
efficient than the equivalent of sprinkling PRINTF around, especially on a
machine that doesn't have an OS and a notion of standard output.

On Sat, Aug 27, 2005 at 12:48:18PM -0500, Mark Rages wrote:
> On 8/27/05, Byron A Jeff <spamBeGonebyronSTOPspamEraseMEcc.gatech.edu> wrote:
> > "I'm a novice user that wants to build a circuit that keeps my lamp on
> > for one minute after I ask it to turn off. Folks like Xiaofan are
> > recommending that I purchase a $50 PicKit 2 or a $160 ICD2 (or a cheaper
> > clone) to do my development. But I see all of these inexpensive PIC
> > programmers out there. Why should I choose to invest so much for just
> > one simple project?"
>
> One small correction.
>
> The Pickit2 is $35 if you only buy the programmer. Well,
> buy.microchip.com charges $10 for shipping, but you can also buy it
> from DigiKey once they get some in stock.

Thanks for the correction.

>
> As far as the debate you guys are having, it's interesting. To me,
> the pickit2 is a pretty cool prototype device in its own right. The
> bootloader's already installed, and USB hardware/power supply, and it
> comes with some example source code. Who says you must use it as a
> programmer?

Now we're kind of getting somewhere. That falls into my belief system
that the development target should be the focus for the hobbyist, not the
programmer.

The only thing that I see as an issue with the PicKit 2 is its limited
interfaces. If I were going to plunk down serious money for a prototyping
box, I'd like to have more interfaces to it.

Now before we start down this road again, be aware that I've already
been there. I started a prototype of a prototyping board called the
PicDesigner. You can read about it here:

Now that's nearly 3 years ago. The 16F877 should be updated to a 40 pin
USB PIC. As I stated in a response to Wouter earlier, I still see
transparancy issues between the use of USB for the bootloader and USB
for application's development. That may be resolvable with two drivers?

The point is that it's a designer target that can serve as a programmer,
not a programmer that can happen to serve as a prototyping target.

Throw a breadboard that's prewired with power/gnd/IO on the top and
you're ready to rock.

On Sat, Aug 27, 2005 at 02:13:34PM -0400, Olin Lathrop wrote:
> Byron A Jeff wrote:
> > As a gdb user I can appreciate a debugger to a point. I find that
> > simulators help with gross errors. But as a "love what you learn"
> > question, what does the debugger bring to the table that's outside
> > of the scope of "normal" debugging activities using I/O devices
> > such as serial interfaces and LCDs?
>
> I'm amazed you're even asking this, Byron. The big everwhelming advantage
> is that you can single step your code, set break points, and look around at
> state without having to decide up front which limited state you are going to
> spit out at which limited set of circumstances.

So it's the live input that I referred to earlier then? Most everything else
I find equally accessible in a simulator. Breakpoints (with conditionals),
watch windows for particular variables, and the like. And with the gpsim
I/O modules, items such as switches, displays, and the like are accessible
in virtual real time.

>Other advantages:
>
> 2 - You don't have to write the code to send trace information somewhere,
> nor the code to either format it nicely in the PIC, or receive it with a
> special program which formats it for you to see.
>
> 3 - Just the existance of trace code can alter the problem you are trying to
> find. Other code may be moved around, the timing will be different, stack
> usage will be different, etc. Sometimes this will make the original symptom
> disappear, and sometimes it can introduce symptoms that are only due to the
> trace code in the first place.
>
> 4 - Trace code can require hardware resources that are already all in use,
> like extra pins, UART, etc.

Trace code doesn't have to exist in simulation. But I do see the
resource/pertubation issue when running live fire.

I have some "how is it really done" questions. Since I branched off into
bootloader world quite a while ago, I have spent no significant amount of
time working with ICSP/ICD style configurations. PGC and PGD must be used in
these configurations. So what is the trend in terms of applications usage of
these pins? Are they simply dedicated to the ICSP/ICD interface? If they are
multiplexed then how does that interfere with ICSP or ICD?

>
> In short, debugging with a real debugger (ICE even better) is waaaaaay more
> efficient than the equivalent of sprinkling PRINTF around, especially on a
> machine that doesn't have an OS and a notion of standard output.

At this point I'm unsure how I feel about the whole ICD2 vibe. It's relatively
expensive, and I have no tools to use it in my current environment.

Maybe it's time to spend time examining the underlaying infrastructure.
This page: http://www.beyondlogic.org/pic/icd.htm outlines the basic ICD
process. But it's unclear whether the same interface exists in the 18F and
dsPIC families.

This is one of the reasons why I would rather depend on specifications rather
than tools.

On Sat, Aug 27, 2005 at 11:10:07AM -0700, William Chops Westfield wrote:
> On Aug 27, 2005, at 5:55 AM, Byron A Jeff wrote:
>
> >Wouter has pointed out that cost effective programmers have
> >their place because they are cost effective.
>
> Things like the JDM programmer are beyond "cost effective" and
> into the realm of "free tools" that we were just saying were
> so important.

TANSTAAFL! With JDM, Tait and the like one pays in sweat equity.

> Tools are tools; I'm not sure why a hobbyist
> who isn't willing to pay $100 for a compiler would be willing
> to spend $100 for a device programmer...

Bingo! especially when the free tool is effective once some
sweat equity has been invested.

Byron A Jeff wrote:
> I have some "how is it really done" questions. Since I branched off
> into bootloader world quite a while ago, I have spent no significant
> amount of time working with ICSP/ICD style configurations. PGC and
> PGD must be used in these configurations. So what is the trend in
> terms of applications usage of these pins? Are they simply dedicated
> to the ICSP/ICD interface? If they are multiplexed then how does that
> interfere with ICSP or ICD?

Usually I take ICSP into account in a design, but not specifically ICD2
since I'll be using an ICE for anything serious. Customers are almost
universally using ICSP during the production test process to put the latest
code on the PIC as part of the manufacturing process. Most of the time ICSP
can be dealt with without too much trouble. The hardest is when using 10Fs.
When the PIC only has 6 pins and 5 of them use used for programming, it
becomes a major design consideration. The larger the PIC the easier it is
to just dedicate lines for ICSP, or find compatible uses to multiplex the
pins with.

> As I stated in a response to Wouter earlier, I still see
> transparancy issues between the use of USB for the bootloader and USB
> for application's development. That may be resolvable with two
drivers?

I think uChip has the same issue with the ICD2, which has a bootloader
and the debugger firmware. When you install the ICD2 you have to install
*two* USB drivers.

Hopefully you would apprecaite the advantage of
real-time debug provided by ICD2/ICE2000/4000
after Olin's post.

I agree that Starting PIC hobbyists may want to work with
JDM first even though I still think Wisp628/EasyProg/Pickit2
is better. However there are PIC hobbyists doing adavnced
projects as well after finishing the blink-a-led project
and ICD2 will serve them well for the higher-end 18F and
dsPIC development.

There are various posts related to the need of
Microchip to opening the interface of the on-chip debug
specifications and the communication protocol of
ICD2 (progrmaming and debug) in the Microchip Forum.
Microchip Forum moderators choose to be silent right now.
I am going to ask again in the Forum.

On Sun, Aug 28, 2005 at 08:35:09AM +0800, Chen Xiao Fan wrote:
> Hopefully you would apprecaite the advantage of
> real-time debug provided by ICD2/ICE2000/4000
> after Olin's post.
>
> I agree that Starting PIC hobbyists may want to work with
> JDM first even though I still think Wisp628/EasyProg/Pickit2
> is better.

I think JDM has problems because it depends on RS232 voltages
to be proper. Simply adding a MAX232 and an external 5V
supply (from USB for example) would make a JDM style programmer
completely stable for virtually any flash part. Randy at
glitchbuster.com has MAX232s for $0.69 USD. Coupled with
$1.85 USD shipping, one can get started for under $5 USD.

> However there are PIC hobbyists doing adavnced
> projects as well after finishing the blink-a-led project
> and ICD2 will serve them well for the higher-end 18F and
> dsPIC development.

I think it's the difference between dipping a toe in the
pool and jumping in the deep end. Development isn't binary.
A novice could crank out a dozen projects before needing
serious debugging firepower.

Oh yes, you add US$5 (RS232 level shifter) and another US$5
(power supply) and will most likely get JDM right.
To draw current from USB port will add some money as well
(USB connector and cable cost quite a bit in USA but may be
much cheaper elsewhere. It is amazing that people can get
DSL router for free after rebate from Bstbuy and other places
but need to pay US$10 to US$20 to get the network cable.)

Why not add another US$5 (16F628 and some capacitors)
to get a Wisp628 or better add another US$5 to US$10 to get a
USB version of Wisp628 or similar (all price estimated )?
Anyway I think the JDM argument is not of too much interests
in this thread anymore.

Now the question is about whether we need an ICD2 or similar
debugging tools for dsPIC development. Price is not a real
issue if another US$10 is spent. Cheapest serial only
ICD2 can be built within budget of US$20 if time>>money IMHO
without the supply and the serial cable (US$10?).

The hobbyists can make use of the excellent Microchip sampling
program to get DIP package of PIC16F876/877/876A/877A to get
this done with less than US$15 or less IMHO on a breadboard,
not including the power supply and serial cable. Then again
there will be problems but you can fixed it by adding US$5
supply or to draw from USB port (USB connectors and cables
cost money as well).

May I ask some questions as the result of all these discussions.
"Suppose you are an hobbyist who are interested in using
higher-end 18F like 18F USB and dsPIC, are you willing to spend
US$30 plus shipping for a debugger and programmer like a cheap
serial only ICD2 clone after reading the benefits listed below?

Are you willing to pay US$70 plus shipping for a full-blown
and more robust USB/Serial ICD2 clone later for convenience?

How long will you need serious debugging power provided by
ICD2 after finished your first blinking a LED project with
a higher-end 18F or dsPICs?"

"The advantage of an ICD2 as a programmer is that it supports
most Flash PICs including dsPICs."

>From Olin's excellent post regading the advantages of debuggers.
"1 - The big everwhelming advantage of ICD2 as a debugger is that you
can single step your code, set break points, and look around at state
without having to decide up front which limited state you are going to
spit out at which limited set of circumstances. Other advantages:

2 - You don't have to write the code to send trace information
somewhere, nor the code to either format it nicely in the PIC,
or receive it with a special program which formats it for you to see.

3 - Just the existance of trace code can alter the problem you are
trying to find. Other code may be moved around, the timing will be
different, stack usage will be different, etc. Sometimes this will
make the original symptom disappear, and sometimes it can introduce
symptoms that are only due to the trace code in the first place.

4 - Trace code can require hardware resources that are already all in
use, like extra pins, UART, etc.
In short, debugging with a real debugger (ICE even better) is way more
efficient than the equivalent of sprinkling PRINTF around, especially
on a machine that doesn't have an OS and a notion of standard output."

On Sun, Aug 28, 2005 at 11:13:30AM +0800, Chen Xiao Fan wrote:
> Oh yes, you add US$5 (RS232 level shifter) and another US$5
> (power supply) and will most likely get JDM right.
> To draw current from USB port will add some money as well
> (USB connector and cable cost quite a bit in USA but may be
> much cheaper elsewhere. It is amazing that people can get
> DSL router for free after rebate from Bstbuy and other places
> but need to pay US$10 to US$20 to get the network cable.)
>
> Why not add another US$5 (16F628 and some capacitors)
> to get a Wisp628 or better add another US$5 to US$10 to get a
> USB version of Wisp628 or similar (all price estimated )?
> Anyway I think the JDM argument is not of too much interests
> in this thread anymore.

You're trying to dismiss it. I'm not going to allow that.
The MAX232 is the level shifter. I've already given you a
price of $0.69 USD. You can get power directly from the PC.
The MAX232 already has a voltage doubler that generates 9V
which is enough to provide a Vpp for flash parts.

The Wisp628 is not just a 628 and some caps. You still need to
program the part with its firmware.

While I may agree that the JDM can have its problems due to
flaky serial ports, there's no reason to believe that such
problems would exist with a proper RS-232 based level converter
at the far end.

You casually dismiss the difference between $5 and $40.
For many hobby folks, that difference can be significant.

Oh and by the way, they would still have to put together a
bootstrap programmer to program the 628.

> Now the question is about whether we need an ICD2 or similar
> debugging tools for dsPIC development. Price is not a real
> issue if another US$10 is spent. Cheapest serial only
> ICD2 can be built within budget of US$20 if time>>money IMHO
> without the supply and the serial cable (US$10?).

What about complexity then? Have you actually gone and taken a
look at an ICD2 clone? You can find one here:

It has a 16F877A, a MAX232, and a Cypress USB interface chips
among 16 ICs and a ton of resistors, caps, and crystals.

Now a novice is supposed to somehow put this bad boy together?!
And oh by the way they have to develop another programmer to get the bootloader
into the 16F877A.

I'll have a seat and wait for that to happen.

> The hobbyists can make use of the excellent Microchip sampling
> program to get DIP package of PIC16F876/877/876A/877A to get
> this done with less than US$15 or less IMHO on a breadboard,
> not including the power supply and serial cable. Then again
> there will be problems but you can fixed it by adding US$5
> supply or to draw from USB port (USB connectors and cables
> cost money as well).

Substituting complexity and high cost for simplicity and low cost
is a recipie for disaster.

>
> May I ask some questions as the result of all these discussions.

Actually I will pass. I'm pretty sure you know where I stand on the
subject. But I'd be interested in hearing what other folks think.

In terms of ICD2 clone, I have made one using the simplest
form and I am qualified to say the cost will be below US$25.
$20 profit will make it to of US$45.

This Chinese shop is selling assembled serial ICD2 at RMB260 (US$33)
including a serial cable, a 6-pin debug cable and a 9V supply.
They used to sell the unsssembled parts at less than US$25. The
shipment within China is about US$5.

It seems to me that I can make a fortune by selling this thingy
and I will be another Wouter. :) I need to look at this seriously. :)
The fully assembled USB version is about US$75 in this shop in single
piece quantity.

>> This Chinese shop is selling assembled serial ICD2 at RMB260
>> (US$33)
>> including a serial cable, a 6-pin debug cable and a 9V supply.
>> They used to sell the unsssembled parts at less than US$25. The
>> shipment within China is about US$5.
>>
>> http://www.nbglin.com/cpjs/dpj12.htm (Never mind the Chinese, just
>> look at the number and picture.)

Byron A Jeff wrote:
> The MAX232 already has a voltage doubler that generates 9V
> which is enough to provide a Vpp for flash parts.

Some yes, some no. It's right on the edge for parts like the 18F2520, which
requires Vdd + 4V. The zero margin for error would make be nervous, even
though you can probably get away with it most of the time.

>...<
> They allow a clone ICD2 market just because they want to sell more chips.

I agree - at the seminar that I attended a few months ago, it was obvious that their "pushing" of the
development boards, of which there are now a large number, was to demonstrate the capabilities of their chips,
not to make money selling the development boards.

That's an interesting link - what is the "PICPRO" on that site? (My PC doesn't display Chinese characters,
and I couldn't read them even if it did!) It looks like some sort of self-contained programmer - is that
right?

I don't think the hobby industry in general is well served by having
"everyone" sell clones of the same microchip programmer, competing on
price until none of the vendors is happy with the profit they're making
on it. Do something different: maybe a protoboard that looks like an
ICD2 to mplab (and has an an ICD connector going out, so that
it CAN be an ICD clone as well) or something like that.

> I don't think the hobby industry in general is well served by having
> "everyone" sell clones of the same microchip programmer, competing on
> price until none of the vendors is happy with the profit they're making
> on it. Do something different: maybe a protoboard that looks like an
> ICD2 to mplab (and has an an ICD connector going out, so that
> it CAN be an ICD clone as well) or something like that.
>
Yes a good prototyping board would be very welcome.
As I couldn't find one,
I just build this prototype board (specially for JAL)
and although I used it only for a few weeks,
I'm very happy with it ;-) ;-)
seehttp://oase.uci.kun.nl/~mientki/pic/projects/rapid_prototyping/rapid_prototyping_devices.html

> Yes a good prototyping board would be very welcome.
> As I couldn't find one,
> I just build this prototype board (specially for JAL)
> and although I used it only for a few weeks,
> I'm very happy with it ;-) ;-)

I know Stef (and you know that I know, and ...), but this is *your*
ideal of a protoboard. You remeber some time ago the piclist tried to
agree on the ideal protoboard?

> > $60 : http://www.voti.nl/shop/p/PIC-TINY-ICD2.html
> >
>
> I don't think the hobby industry in general is well served by having
> "everyone" sell clones of the same microchip programmer, competing on
> price until none of the vendors is happy with the profit
> they're making on it.

? I don't see how that would harm the hobby industry. The price would go
down, and at least on seller would remain. But there is nothing special
in this ICD2 clone I sell: it is made by Olimex and sold by a lot of
shops.

> Do something different: maybe a protoboard that looks like an
> ICD2 to mplab (and has an an ICD connector going out, so that
> it CAN be an ICD clone as well) or something like that.

I don't see the sense in that. Separating the ICD2 and the protoboard
would make more sense, so people can mix and match as they see fit. BTW
I do sell a range of boards more or less like that.

On Sun, Aug 28, 2005 at 11:08:20PM +0200, Wouter van Ooijen wrote:
> > Yes a good prototyping board would be very welcome.
> > As I couldn't find one,
> > I just build this prototype board (specially for JAL)
> > and although I used it only for a few weeks,
> > I'm very happy with it ;-) ;-)
>
> I know Stef (and you know that I know, and ...), but this is *your*
> ideal of a protoboard. You remeber some time ago the piclist tried to
> agree on the ideal protoboard?

I do! I do!

I even prototyped the prototype board. You can find the designer here:

I am eventually planning on placing a breadboard with permanently
installed I/O on the top of the Designer.

Stef doesn't have a bad concept. I kind of like the idea of a board
with lots of connectors. Also a standard daughterboard/jumper cable
concept isn't too bad either.

Question for Stef: Why did you only use it a few weeks?

I think the one thing I realized since our discussion 3 years ago
is that the ideal prototyping board would be a starter board that
lightly populated, but already had all of the pads for future expansion
in place.

The idea is as sound as it was during the "Furious Debates of 2002!".
Building infrastructure to start a project is a chore. Something that
facilitates rapid prototyping for early success would be the ticket.
The prototyper would of course have to double as a code dumper so that
finished project can be transferred off the prototyper.

>> I don't think the hobby industry in general is well served by
>> having
>> "everyone" sell clones of the same microchip programmer, competing
>> on
>> price until none of the vendors is happy with the profit
>> they're making on it.

The invisible hand of the market at work :-).
Alas, the opposite is (almost always) only one maker selling them at a
noncompetitve price and being *VERY* happy with the profit they're
making.

Striking a "reasonable" balance seems difficult to do.
Some argue, of course, that the invisible hand IS the reasonable
balance.

Nice. The "trick" with prototype boards seems to be to strike
some sort of balance between cost/complexity of the board itself,
and expandability. Your device bus is an interesting attempt in
that direction. I keep thinking of building something based on
RJ45 connectors (since they're so common these days), but it always
seemed that the pin count would be too low. Based on your experience,
perhaps not... (Alas, they are painful to build with as well, in a
hobbyist context.) (likewise, I'm surprised that simmsticks didn't
catch on more...)

>
> On Aug 28, 2005, at 1:46 PM, Stef Mientki wrote:
>
>> I just build this prototype board (specially for JAL)
>> I'm very happy with it ;-) ;-)
>>
>> http://oase.uci.kun.nl/~mientki/pic/projects/rapid_prototyping/
>> rapid_prototyping_devices.html
>
So why aren't you selling them? I would love to buy one! And although
I feel sure that you do not want to be a zillionaire, because mere money
is so crass, still . . .

>> I don't think the hobby industry in general is well served by having
>> "everyone" sell [ICD clones]

> ? I don't see how that would harm the hobby industry. The price would
> go
> down, and at least on seller would remain.

With the others having wasted time and effort trying to make a better
product, only to be beaten on price by China?

> But there is nothing special in this ICD2 clone I sell: it is made
> by Olimex and sold by a lot of shops.

This, on the other hand, is fine. Lots of people selling the same
ICD2 clone designed by a single manufacturer is less wasteful of
effort...

>
>> Do something different: maybe a protoboard that looks like an
>> ICD2 to mplab ...
>
> I don't see the sense in that. Separating the ICD2 and the protoboard
> would make more sense, so people can mix and match as they see fit

We call it "value add" - "What can I do to add value to this design
so that people will buy MY clone rather than that other guys..." Alas,
the things that people consider 'added value' tend to be variable and
difficult to quantify...

> BTW I do sell a range of boards more or less like that.

The dwarf boards? Yep. Are they popular? I think the last really
successful "new" peripheral connect came from the basic stamps ability
to do serial output on any pin; engendering a range of peripherals
with a single serial input, including (IIRC) "serial LCDs" which seem
to have become immensely popular... Simmsticks and dwarf boards seem
like they OUGHT to be more popular!

There are no better ICD2s than Microchip's original ICD2. All
of the clones are using Microchip's design (to cut some corners
sometimes to reduce the price) and Microchip's firmware. Therefore
the Chinese shops are doing fine here. They are not copying the
Olimex design (if it is qualified to be called a Olimex design).

There may be problems related to IP protection in China but this
is not the case here. At least it is not worse than any other
clone makers. I myself have reservations of ICD2 clones regarding
the IP. However I have no problem with them if Microchip does not
have problems with them. Here BAJ is correct. Microchip should
publish the on-chip debug specifications (now only PIC12/14 are
available) and people can produce their own debuggers. PIKdev is
one of such examples (I think only for PIC12/14 architecture now).

Some of them (the S$85 type from pic16.com) are almost exact
clone of Microchip ICD2 with the Cypress chip inside. The two
main distributors are actually making ICD2 and PS+ clone with
the authorization from Microchip. Of course they will be more
expensive than pic16.com since they print Microchip logo on
the housing. They are also not allowed to export to other
countries without the permission from Microchip. This is the
information I get from Chinese Forums.

By the way, lots of the Chinese hobbyists built their own ICD2
clones since US$33 (serial only assembled ICD2 from nbglin.com) or
US$85 (usb/serial ICD2 from pic16.com) are still too much for
quite some people there. So I do not quite understand BAJ's claim
that ICD2 clones are so difficult to build.

Yes it is a self-contained production programmer (a cheap
Promate II/III but looks like ICSP only??).
Maybe you can try Rusell's link to translate it into English.

However I believe this will not be so cheap. It is said that
this company has quite okay service but the price is always
on the high side. It is the same for the other company named
Burnon. They both produce the Microchip endorsed PS+ and ICD2
and the price is not so cheap as well. That is why still a lot
of the Chinese hobbyists and SOHOs are using the clone ICD2 and
PS+.

>
> On Aug 28, 2005, at 1:46 PM, Stef Mientki wrote:
>
>> I just build this prototype board (specially for JAL)
>> I'm very happy with it ;-) ;-)
>>
>> http://oase.uci.kun.nl/~mientki/pic/projects/rapid_prototyping/
>> rapid_prototyping_devices.html
>
>
> Nice. The "trick" with prototype boards seems to be to strike
> some sort of balance between cost/complexity of the board itself,
> and expandability. Your device bus is an interesting attempt in
> that direction. I keep thinking of building something based on
> RJ45 connectors (since they're so common these days), but it always
> seemed that the pin count would be too low. Based on your experience,
> perhaps not... (Alas, they are painful to build with as well, in a
> hobbyist context.) (likewise, I'm surprised that simmsticks didn't
> catch on more...)

Because I do a lot with analog electronics, I needed a separate analog
ground / power supply.
So if you forget the analog power supply, I use only 8 pins.
Another reason why I choose this connector, because it's cheap (RJ45 too),
a small disadvantage is that I didn't find an female printboard
connector yet,
so I'm now using the flatcable part on the device boards.

There are some devices, like 4*4 keypad, IDE-bus, which cann't be easily
connected.
But a solution would be to add some (4) extra larger connectors,
which could even be compatible with some other board, like dwarf boards.

On 8/29/05, Wouter van Ooijen <KILLspamwouterspamBeGonevoti.nl> wrote:
> > Yes a good prototyping board would be very welcome.
> > As I couldn't find one,
> > I just build this prototype board (specially for JAL)
> > and although I used it only for a few weeks,
> > I'm very happy with it ;-) ;-)
>
> I know Stef (and you know that I know, and ...), but this is *your*
> ideal of a protoboard. You remeber some time ago the piclist tried to
> agree on the ideal protoboard?

THE piclist can agree with something ?
:))))
That's the beauty of piclist, no one is agree with others. Stef's
protoboard could be the perfect thing on the world for a guy which
does not have two left hands and only software abilities. But it
required some hardware skills which many people forgot in the era of
computer simulation.

>IMHO simmsticks are too much to the 'less flexible' side of the
>continuuum you decsribed, and Stef's boards perhaps too much to the
>flexible side.
>
>
>
A prototyping board can never be too flexible ;-)
Stef

>
> On Aug 28, 2005, at 9:53 AM, Wouter van Ooijen wrote:
>
> >> The fully assembled USB version is about US$75 in this
> >> shop in single piece quantity.
> >
> > $60 : http://www.voti.nl/shop/p/PIC-TINY-ICD2.html
> >
>
> I don't think the hobby industry in general is well served by having
> "everyone" sell clones of the same microchip programmer

Are you calling Wouter "everyone"? :-)

> Do something different: maybe a protoboard that looks like an
> ICD2 to mplab (and has an an ICD connector going out, so that
> it CAN be an ICD clone as well) or something like that.

Well the one Wouter is selling isn't made by him, it's from Olimex I believe, and he's performing a useful
service by selling it (Olimex can be a right pain to buy from in some parts of Europe).

But I agree, there's no point designing more clones - adding extras to the design would be a Good Thing. The
"extra" that this particular item has is its small size - you can carry it around in a shirt pocket, if that's
your idea of a good time...

Byron A Jeff wrote:
> Building infrastructure to start a project is a chore. Something that
> facilitates rapid prototyping for early success would be the ticket.

That's part of the concept behind the QuickProto series
(http://www.embedinc.com/products), coming Real Soon Now (units supposedly
on their way to me from China right now).

> The prototyper would of course have to double as a code dumper so that
> finished project can be transferred off the prototyper.

I don't agree with this at all. You only need one programmer, or code
dumper if you want to go that route, but you will probably do multiple
projects. It doesn't make sense to burden each prototyping board with a
programmer. Besides, my concept of a prototyping board is that it *is* the
finished project for a one-off. The prototyping board takes care of the
standard infrastructure without dictating the project to the extent
possible, and leaves generous room for you to add your project-specific
stuff. Of course any infrastructure provided will limit some choices for
the end project, so some judgements and tradeoffs need to be made. There is
no single right answer. That's why I plan on making a series of different
QuickProto boards, but also realize that I'll never make everyone happy all
the time. The QuickProto-01 is my judgement of the most widely appealing
prototyping board for the most common unspecialized middle of the road
project.

On Mon, Aug 29, 2005 at 07:54:34AM -0400, Olin Lathrop wrote:
> Byron A Jeff wrote:
> >Building infrastructure to start a project is a chore. Something that
> >facilitates rapid prototyping for early success would be the ticket.
>
> That's part of the concept behind the QuickProto series
> (http://www.embedinc.com/products), coming Real Soon Now (units supposedly
> on their way to me from China right now).
>
> >The prototyper would of course have to double as a code dumper so that
> >finished project can be transferred off the prototyper.
>
> I don't agree with this at all. You only need one programmer, or code
> dumper if you want to go that route, but you will probably do multiple
> projects.
> It doesn't make sense to burden each prototyping board with a
> programmer.

Hold on Olin. We're talking about two different items.

> Besides, my concept of a prototyping board is that it *is* the
> finished project for a one-off. The prototyping board takes care of the
> standard infrastructure without dictating the project to the extent
> possible, and leaves generous room for you to add your project-specific
> stuff.

> Of course any infrastructure provided will limit some choices for
> the end project, so some judgements and tradeoffs need to be made. There is
> no single right answer. That's why I plan on making a series of different
> QuickProto boards, but also realize that I'll never make everyone happy all
> the time. The QuickProto-01 is my judgement of the most widely appealing
> prototyping board for the most common unspecialized middle of the road
> project.

Agreed. Now to differentiate the other prototype box. This is a prebuilt
rapid prototyper which hangs a chip, interface, and a set of standard
fixtures in a box. This is a permanent development box that sits on your
desk to noodle with. Once you get your idea down, you can then transfer
it to the type of board you referred to above.

At 07.54 2005.08.29 -0400, you wrote:
>Byron A Jeff wrote:
>>Building infrastructure to start a project is a chore. Something that
>>facilitates rapid prototyping for early success would be the ticket.
>
>That's part of the concept behind the QuickProto series
>(http://www.embedinc.com/products), coming Real Soon Now (units supposedly
>on their way to me from China right now).

How many do you make the Chinese company manufacture for you each run?
Do they make everything (PCB and soldering)? Do you send the components,
or do they even provide them?

>>The prototyper would of course have to double as a code dumper so that
>>finished project can be transferred off the prototyper.
>
>I don't agree with this at all. You only need one programmer, or code
>dumper if you want to go that route, but you will probably do multiple
>projects. It doesn't make sense to burden each prototyping board with a
>programmer. Besides, my concept of a prototyping board is that it *is* the
>finished project for a one-off. The prototyping board takes care of the
>standard infrastructure without dictating the project to the extent
>possible, and leaves generous room for you to add your project-specific
>stuff. Of course any infrastructure provided will limit some choices for
>the end project, so some judgements and tradeoffs need to be made. There is
>no single right answer. That's why I plan on making a series of different
>QuickProto boards, but also realize that I'll never make everyone happy all
>the time. The QuickProto-01 is my judgement of the most widely appealing
>prototyping board for the most common unspecialized middle of the road
>project.
>
>
>*****************************************************************
>Embed Inc, embedded system specialists in Littleton Massachusetts
>(978) 742-9014, http://www.embedinc.com

> Agreed. Now to differentiate the other prototype box. This is
> a prebuilt
> rapid prototyper which hangs a chip, interface, and a set of standard
> fixtures in a box. This is a permanent development box that
> sits on your
> desk to noodle with. Once you get your idea down, you can
> then transfer
> it to the type of board you referred to above.

Olin states (and I agree) that he prefers that kind of prototype box
*minus the programmer*. That way he
- needs only one programmer
- it can be the programmer of his choice
- when he uses the prototype box as end product for small series he
saves the cost of the progger on each board

Electron wrote:
> How many do you make the Chinese company manufacture for you each run?
> Do they make everything (PCB and soldering)? Do you send the components,
> or do they even provide them?
>
> Just curious. :)

Some of all of these things. I don't really want to comment on this process
at this time, especially since the process hasn't completed yet.

It does sorta look like one of those board that is easier to
wire point-to-point (or WW) than to do as a PCB. A double sided
PCB would probably do OK, but it wouldn't be an easy-for-beginners
single-sided PCB, either :-(

It does sorta look like one of those board that is easier to
wire point-to-point (or WW) than to do as a PCB. A double sided
PCB would probably do OK, but it wouldn't be an easy-for-beginners
single-sided PCB, either :-(

On Mon, Aug 29, 2005 at 05:10:49PM +0200, Wouter van Ooijen wrote:
> > Agreed. Now to differentiate the other prototype box. This is
> > a prebuilt
> > rapid prototyper which hangs a chip, interface, and a set of standard
> > fixtures in a box. This is a permanent development box that
> > sits on your
> > desk to noodle with. Once you get your idea down, you can
> > then transfer
> > it to the type of board you referred to above.
>
> Olin states (and I agree) that he prefers that kind of prototype box
> *minus the programmer*.

No. Olin is talking about a blank stock prototyping board that you have to
populate. A board with enough standard interfaces that you can quick throw
different types of standard stuff (LCDs, switches, LEDs, analog via PWM, etc.)
on it.

That prototyper then becomes the project target. So instead of having to
develop a custom PCB, you have a stack of blanks for new projects.

I get it. I buy into the concept. I think it's an excellent idea. And
I agree that it doesn't need a programmer, just maybe and ICSP connector
so that it can be programmed.

It's just that when the mood strikes me for an idea, I don't want to have
to populate anything. So I'm thinking of a permanent board. Something like:

...or a beefed up PicKit. Call it a proof of concept box, or a rapid
prototyper. Sometimes it takes only a few minutes to realize that an idea is
goofy and should be abandoned or seriously rethought.
OTOH populating a blank board will take time to get whichever set of standard
components needed for a particular idea going.

>That way he
> - needs only one programmer
> - it can be the programmer of his choice
> - when he uses the prototype box as end product for small series he
> saves the cost of the progger on each board

No arguments. But as I said, we're talking about two different, but complimentary
tools. Olin's QuickProto (sp?) would serve as a stock "motherboard" for one off
projects. OTOH the rapid prototyper would be an instant development box, no
soldering necessary.

They could really complement one another if the rapid prototyper and the blank
boards had the same interfaces. This would facilitate easy transfer of projects
from off the rapid prototyper to its more permanent home.

You can get a value add from the rapid prototyper if it contained an ICSP programmer
too. That's the point I've been making. So when you're ready to do the final
transfer from the rapid prototyper to the QuickProto PCB, you don't have to have
another programmer laying around simply to program the part for the QuickProto.

It would even be worth incorporating ICD at that point.

Truthfully Olin and I are not really talking about different items, just different
usage. Olin said that one size does not fit all. Very true for one off targets.
But for a rapid prototyper you want it bo be as large, as generic and as flexible
as possible. It serves as the initial scaffolding for project development. It
serves as a temporary home for a budding project. As such it should incorporate
an array of standard items along with ways to hook up project specific stuff.

PC developers do not build new computers for each new project that they start.
Development starts on an existing machine. If it fizzles out, then so be it.
However if the project idea takes, then you start thinking about new hardware to
run it.

The rapid prototyper is an analog for that. I take the Don Lancaster tack on
project development: you'll have a bunch of failures before a good one survives.
In my mind it's like dating a project. I certainly don't want to invest much just
for a date. Putting solder to PCB, even on a stock prefab prototyping PCB is simply
too much of a committment... initially. If I warm up to the project, then it can
be transferred to its own separate board. If not, then tear down the breadboard
part and then the rapid protyping scaffolding is in place for the next "great"
idea.

So the rapid prototyper is a tool that serves as an instant temporary target.
But it's going to be a permanent fixture on the desk. So it's OK to incorporate
a programmer, a breadboard, ICD, and the like.

Not true for the final target, which will need an array of sizes to fit different
needs. That will be one offs so they need to be unpopulated and does not need
to incorporate a programmer (except for maybe and ICSP connector or a bootloader
interface that costs 1 I/O pin).

On Mon, Aug 29, 2005 at 10:35:49PM -0400, Byron A Jeff wrote:
> On Mon, Aug 29, 2005 at 05:10:49PM +0200, Wouter van Ooijen wrote:
> > > Agreed. Now to differentiate the other prototype box. This is
> > > a prebuilt
> > > rapid prototyper which hangs a chip, interface, and a set of standard
> > > fixtures in a box. This is a permanent development box that
> > > sits on your
> > > desk to noodle with. Once you get your idea down, you can
> > > then transfer
> > > it to the type of board you referred to above.
> >
> > Olin states (and I agree) that he prefers that kind of prototype box
> > *minus the programmer*.
>
> No. Olin is talking about a blank stock prototyping board that you have to
> populate.

I want to call myself out on this one. The QuickProto isn't blank. Chip, power,
RS232, and a sea of holes are all in place.

> It's just that when the mood strikes me for an idea, I don't
> want to have
> to populate anything. So I'm thinking of a permanent board.
> Something like (snip)

I don't think you will ever come up with a PCB that covers more than a
few projects. I prefer a more flexible approach Dwarf Boards, SimmStick,
or Stefs' apperoach, which is all the same idea but with different
choices of the interconnect width.

On Tue, Aug 30, 2005 at 08:05:59AM +0200, Wouter van Ooijen wrote:
> > It's just that when the mood strikes me for an idea, I don't
> > want to have
> > to populate anything. So I'm thinking of a permanent board.
> > Something like (snip)
>
> I don't think you will ever come up with a PCB that covers more than a
> few projects. I prefer a more flexible approach Dwarf Boards, SimmStick,
> or Stefs' apperoach, which is all the same idea but with different
> choices of the interconnect width.

That idea is perfectly fine. It adds to the flexibility that I referred to
in my previous post. It's just that I'd like to have a fixture or a container
with some common items affixed to the board. They can even be attached by
cables along the lines of your dwarf connectors.

But having all those small boards loose and floating around is a nightmare
scenario to me. I know I'll never be able to find the board that I need when
I really need it.

So what's wrong with a permanent fixture where everything is mounted? It's
a whole lot more difficult to misplace one larger box/board than it is to
misplace a dozen small boards.

> That idea is perfectly fine. It adds to the flexibility that
> I referred to
> in my previous post. It's just that I'd like to have a
> fixture or a container
> with some common items affixed to the board. They can even be
> attached by
> cables along the lines of your dwarf connectors.

So I was talking about PCBs, and you were talking about a box/plate
level fixture? In that case there is no disagreement :)

> But having all those small boards loose and floating around
> is a nightmare
> scenario to me. I know I'll never be able to find the board
> that I need when
> I really need it.

I just grab the two boxes labeled 'Dwarfs' :)

> So what's wrong with a permanent fixture where everything is
> mounted?

My setups are often varying, and I often need more than one. I don't
want to have three large plates around, each carrying everything I might
need!

Right now I needed (for debugging) something to display ASCII data sent
by IR. I just grabbed a CPU DwarfBoard, added an LCD, and soldered a
TDOP1736 to a DB cable. This arrangement won't surive the end of this
week, next week I'll need something different.

> Right now I needed (for debugging) something to display ASCII data
> sent
> by IR. I just grabbed a CPU DwarfBoard, added an LCD, and soldered a
> TDOP1736 to a DB cable. This arrangement won't surive the end of
> this
> week, next week I'll need something different.

>On Mon, Aug 29, 2005 at 05:10:49PM +0200, Wouter van Ooijen wrote:
>
>
>>>Agreed. Now to differentiate the other prototype box. This is
>>>a prebuilt
>>>rapid prototyper which hangs a chip, interface, and a set of standard
>>>fixtures in a box. This is a permanent development box that
>>>sits on your
>>>desk to noodle with. Once you get your idea down, you can
>>>then transfer
>>>it to the type of board you referred to above.
>>>
>>>
>>Olin states (and I agree) that he prefers that kind of prototype box
>>*minus the programmer*.
>>
>>
>
>No. Olin is talking about a blank stock prototyping board that you have to
>populate. A board with enough standard interfaces that you can quick throw
>different types of standard stuff (LCDs, switches, LEDs, analog via PWM, etc.)
>on it.
>
>That prototyper then becomes the project target. So instead of having to
>develop a custom PCB, you have a stack of blanks for new projects.
>
>I get it. I buy into the concept. I think it's an excellent idea. And
>I agree that it doesn't need a programmer, just maybe and ICSP connector
>so that it can be programmed.
>
>

However, soldering components, or rather trying to unsolder components
is a non-starter, so perhaps Wouters mini-boards idea is better -- the
main board is permanently stuffed, and the daughter boards added as
needed.

Still, I am happy with my board as I have successfully prototype several
applications with it.

On Tue, Aug 30, 2005 at 01:38:39PM +0200, Wouter van Ooijen wrote:
> > That idea is perfectly fine. It adds to the flexibility that
> > I referred to
> > in my previous post. It's just that I'd like to have a
> > fixture or a container
> > with some common items affixed to the board. They can even be
> > attached by
> > cables along the lines of your dwarf connectors.
>
> So I was talking about PCBs, and you were talking about a box/plate
> level fixture? In that case there is no disagreement :)

Ahh. Concensus.

>
> > But having all those small boards loose and floating around
> > is a nightmare
> > scenario to me. I know I'll never be able to find the board
> > that I need when
> > I really need it.
>
> I just grab the two boxes labeled 'Dwarfs' :)

I always have a tough time locating those boxes.

> > So what's wrong with a permanent fixture where everything is
> > mounted?
>
> My setups are often varying, and I often need more than one. I don't
> want to have three large plates around, each carrying everything I might
> need!

Those are orthogonal issues I think. If you're talking about more than one
then I think you're right that a more traditional protoboard setup like
Dwarf and QuickProto are appropriate for the second one.

> Right now I needed (for debugging) something to display ASCII data sent
> by IR. I just grabbed a CPU DwarfBoard, added an LCD, and soldered a
> TDOP1736 to a DB cable. This arrangement won't surive the end of this
> week, next week I'll need something different.

I envisioned something similar. In my case the LCD would have already
been mounted. Just plug it into a port. Also I'd have a breadboard. No
soldering necessary.

The point is have a grab it and go type box with enough fixtures and
enough flexibility that you can get most things started easily.

> >
> >That prototyper then becomes the project target. So instead of having to
> >develop a custom PCB, you have a stack of blanks for new projects.
> >
> >I get it. I buy into the concept. I think it's an excellent idea. And
> >I agree that it doesn't need a programmer, just maybe and ICSP connector
> >so that it can be programmed.
> >
> >
> I designed my OmniPort board to be a do-it-all board
> (http://www.dpharris.ca/index.pl/block_diagram) and it works fine. I
> populated one with lots of sockets and it is a great prototyping board.

That's the idea. And you only need one (or maybe two) for general purpose
prototyping.

> However, soldering components, or rather trying to unsolder components
> is a non-starter, so perhaps Wouters mini-boards idea is better -- the
> main board is permanently stuffed, and the daughter boards added as
> needed.

Agreed. For a proof of concept, I don't want to have to solder anything right
then and there. So a breadboard or sets of jumper sockets like Stef's are
appropriate.

> Still, I am happy with my board as I have successfully prototype several
> applications with it.

I'ld like to emphasize some other features of my design
1. The modularity is extended to the software
2. The modularity is extended to the definite design
3. I need to work at 2 different places on the same project
4. I need at least 20 different often used modules and maybe 10 less
frequently used

ad 1:
I normally use JAL to program my PICs, I've written a shell around JAL
(JALcc),
where I can add the total functionality of each module with just 1 line
of code,
e.g. to add an 2*16 LCD module on connector J3 :
RPD_LCD Display = J3, 2, 16

ad 2:
All modules (the modules shown are just a few hobby modules) are not
tricked to fit into the prototyping board,
but are designed in such a way, that it's exactly the same circuit that
will be used in the final design. Normally we make a sketch of the final
circuit, some external firm, does the final drawing, we've to check it,
the external firm is doing the print design, we've to check it etc. The
idea (I've to contact our external firm) is that the circuit schematics
of each module is inserted in the design package (Eagle) just once, and
reused for the final circuit design. So we can simply specify each
design by atmost 10 simple text lines, and we don't have to check the
design anymore, but just wait for the mounted pcb to arrive. Maybe it's
even possible (but I don't know Eagle god enough for that), to put the
completly routed module into Eagle, which is especially usefull for
critical layouts.

ad 3.
For working at 2 different places, it's necessary that you can easily
transfer the prototyping design from one place to another (I travel by
bike, so transporting is not very reliable ;-). This adds the need for
standard connectors, and not wires in all kind of different holes. Again
with the previous 10 lines of text (which are in fact already in the
software) I can transfer the complete prototyping design.

ad 4.
I agree to fit as many components on the board as possible. But with 30
different modules that's completly impossible. As we almost always use
an USB connection, I indeed added this on the board (but it can be
disabled, and can for instance be replaced by a max232-module).
And indeed the storage of all the 40 modules (30 different + 10
doubles) is indeed an interesting problem,
maybe I'll make some kind of box (with power supplies), with on top the
prototyping board and inside a lot of dummy connectors to store the not
used modules.

On Tue, Aug 30, 2005 at 07:12:46PM +0200, Wouter van Ooijen wrote:
> > I envisioned something similar. In my case the LCD would have already
> > been mounted. Just plug it into a port. Also I'd have a breadboard. No
> > soldering necessary.
>
> But this time a 16x1 LCD is OK. Next time I might need a 320 x 200
> graphical. Yet having the graphical on the board all the time would make
> it too large...

Wouter, I do see your point. To me though it isn't a situation where you have to
choose one to the exclusion of the other.

We can certainly agree that you cannot have everything that you may ever need
onboard. But a board with a handful of commonly used, permanently attached items
would be useful. This doesn't preclude attaching other items as needed.

It certainly functions in the Dwarf style. It has connectors for attaching stuff
and sockets for the PICs and the crystals. Totally cool.

I would put it in a box with a couple of those LED modules, an LCD, a handful of
switches, a pot/opamp combo, and a MAX232/FT232. Also I'd add a breadboard.

Now will that set handle every prototyping project? No. However, it will save time
scrounging up the right combo of stuff.

What about items like the 320x200 graphical? BTW do you have routines for driving
such a device? Nothing precludes wiring one to a 10/20 pin connector and attaching
it for the purposes of a single project. Or soldering a header on it so that it
can be plugged into the breadboard.

On Tue, Aug 30, 2005 at 10:27:07PM +0200, Wouter van Ooijen wrote:
> > What about items like the 320x200 graphical? BTW do you have routines
> for driving
> such a device?
>
> Working on it (at th emoment using an ARM, I don't think a 16F or 18F
> will be enough).

Really? From the last time I worked on a T6963 based LCD, the timing
requirements were not so bad that it couldn't be handled by a parallel
loaded shift register IIRC.

Maybe we've found a job for a high speed dsPIC!

> > Nothing precludes wiring one to a 10/20 pin connector and attaching
> > it for the purposes of a single project. Or soldering a header on it so
> > that it can be plugged into the breadboard.
>
> Indeed, I use 10-pin headers to attach everything :)

On Tue, 30 Aug 2005 16:57:13 -0400, Byron A Jeff wrote:
> On Tue, Aug 30, 2005 at 10:27:07PM +0200, Wouter van Ooijen wrote:
> > > What about items like the 320x200 graphical? BTW do you have
> routines
> > for driving
> > such a device?
> >
> > Working on it (at th emoment using an ARM, I don't think a 16F or
> > 18F will be enough).
>
> Really? From the last time I worked on a T6963 based LCD, the timing
> requirements were not so bad that it couldn't be handled by a parallel
> loaded shift register IIRC.
>
> Maybe we've found a job for a high speed dsPIC!

I think the speed concerns are not with the hardware interface per se but with character drawing speed and the graphics kernel math/calculation speed. A monochrome 320 x 200 display requires 8K display data bytes. A screen update from a local buffer involves transferring 8KB so any delays in wrting to the hardware add up
quickly. The hardware interface speed (LCD controller and I/O read
write speed) and data transfer rate can be significant. Add to that any
time required for calculating bitmaps for fonts, line drawing, etc. and
the display update rate can be perceived as quite slow unless you
minimize the delays.
I recently completed a project with a 320 x 240, 16 gray level display connected to the data bus of a 29MHz Rabbit 2000 CPU and it was only marginally fast enough (as expressed by the client). It took about 200 mS to update the screen via a buffer transfer from Rabbit to LCD frame
memory due to speed restrictions of the LCD controller and the fact
that 16KB of data needed to be transferred.
I'm getting ready to do a 320 x 240 color TFT display for a medical
project and we're planning to use a 40MHz+ ARM7 CPU just because of the
graphics requirements.
But you're right, the dsPIC might be a good choice for a moderate size
graphical LCD panel.

> > Working on it (at th emoment using an ARM, I don't think a
> 16F or 18F
> > will be enough).
>
> Really? From the last time I worked on a T6963 based LCD, the timing
> requirements were not so bad that it couldn't be handled by a parallel
> loaded shift register IIRC.

It does not have a controller.

> Power, GND, and 8 data lines seems like a good plan.

Dwarf Bus :)

But, as good as it sounds, there are things for which 8 data bits are
insufficient (like: RTL8019 Ethernet chip), or too many (see Stef's
design), or were just one ground/one data will not do.

>David,
>
>On Tue, 30 Aug 2005 08:19:01 -0700, David P Harris
>wrote:
>
>
>
>>I designed my OmniPort board to be a do-it-all board
>>(http://www.dpharris.ca/index.pl/block_diagram) and it
>>
>>
>works fine. I
>
>
>>populated one with lots of sockets and it is a great
>>
>>
>prototyping board.
>
>I like the look of this - are boards available to the
>likes of me? I see there are block diagrams but nothing
>more detailed - are there full circuit diagrams
>somewhere?
>
>Cheers,
>
>
>Howard Winter
>St.Albans, England
>
>
>
>

Yes, boards are available, but unfortunately I have sold almost all the
PIC ones, and the rest are for me....however, if there is interest I
will more made (and perhaps change slightly and fix a couple of
things). There are some AVR ones (same layout except sl changes, and
obviously changed pinouts). $5US a board, including shipping (ie cost).

>>>Working on it (at th emoment using an ARM, I don't think a
>>>
>>>
>>16F or 18F
>>
>>
>>>will be enough).
>>>
>>>
>>Really? From the last time I worked on a T6963 based LCD, the timing
>>requirements were not so bad that it couldn't be handled by a parallel
>>loaded shift register IIRC.
>>
>>
>
>It does not have a controller.
>
>
>
>>Power, GND, and 8 data lines seems like a good plan.
>>
>>
>
>Dwarf Bus :)
>
>But, as good as it sounds, there are things for which 8 data bits are
>insufficient (like: RTL8019 Ethernet chip), or too many (see Stef's
>design), or were just one ground/one data will not do.
>
>

However, if you line them up with appropriate spacing, you can use a
single 24 pin connector to connect to two 10 pin connectors, and have 16
i/o and duplicate power and ground, but still use them individually if
needed.

I designed my board with a 4xn i/o layout: pull-up/down, signal,
power/ground, ground/power. This is useful for: 2xn with
signal/pull-up, 3xn servo connections, 2xn input jumpers, 3xn toggle
switch connections, etc. Pull-up/down provided by a resistor network.
In addition, the layout allows a 2803 (or 2983) to be inserted for
moderate drive capacity. There is also additional space for
transistor/Darlington/MOSFET drive, but in a cramped space (heat sinking
would be problematic). Options for a variety of output connections from
0.1" pin headers to 0.1" screw terminals.

> However, if you line them up with appropriate spacing, you can use a
> single 24 pin connector to connect to two 10 pin connectors,
> and have 16
> i/o and duplicate power and ground, but still use them
> individually if
> needed.

That might have been a good idea, but I did not do this when I designed
my PCBs. For some PCBs I wanted the maximum density, for others I wanted
the 10-pin connectors to match up with 8-pin wire cups, which dictated a
different spacing. But I might use this idea some time.

>To the contrary. The ICD2 clone builders don't need the interface
>at all, the only need the bootloader interface, which seems to be
>well known. They ship the clone with the bootloader, and MPLAB
>downloads the real debugger firmware. You of all people will
>appreciate this scheme :) Having the ICD2 debugger interface
>available would enable alternate PC software (Linux or otherwise),
>which can only increase the demand for ICD2s (original or clone).

I would have thought some enterprising type would have passed the download
code through a disassembler by now and worked all this out, after all the
destination chip is a well known one ;)))

>I leave this part of the discussion with a situation:
>
>"I'm a novice user that wants to build a circuit that keeps my
>lamp on for one minute after I ask it to turn off. Folks like
>Xiaofan are recommending that I purchase a $50 PicKit 2 or a
>$160 ICD2 (or a cheaper clone) to do my development. But I see
>all of these inexpensive PIC programmers out there. Why should
>I choose to invest so much for just one simple project?"

What is really needed for this market is some standalone freeware that can
access any debug registers through the JDM style programmer interface.

> I would have thought some enterprising type would have passed
> the download
> code through a disassembler by now and worked all this out,
> after all the
> destination chip is a well known one ;)))

That is not enough. You can reverse-engineer what the current firmware
requires, but that is not sufficient to create PC support for future
firmware. Remember that the ICD2 is in some sense just hardware with a
bootloader, the firmware is downloaded 'on demand'.

> >> I just grab the two boxes labeled 'Dwarfs' :)
> >
> >I always have a tough time locating those boxes.
>
> Yeah, the little men with short legs keep on relocating them ;)

In fact a little man with short legs is always trying to rearrange my
work place. His main preference is that everything that is boxes should
be on the floor, failing that he prefers all components to be evenly
distributed over all boxes. The fact that I disagree does not seem to
deter him :(

>> I would have thought some enterprising type would have passed
>> the download
>> code through a disassembler by now and worked all this out,
>> after all the
>> destination chip is a well known one ;)))
>
>That is not enough. You can reverse-engineer what the current firmware
>requires, but that is not sufficient to create PC support for future
>firmware. Remember that the ICD2 is in some sense just hardware with a
>bootloader, the firmware is downloaded 'on demand'.

Yeah, but by disassembling the bit that gets downloaded, you can work out
the protocol for the family that module represents. I suspect the protocol
to the host computer is basically the same for all modules, just some of the
bells and whistles bits need to be determined for all modules.

So a collaborative project with different people working on a module each
...

> On Tue, 30 Aug 2005 16:57:13 -0400, Byron A Jeff wrote:
> >?On Tue, Aug 30, 2005 at 10:27:07PM +0200, Wouter van Ooijen wrote:
> >?>?>?What about items like the 320x200 graphical? BTW do you have
> >?routines
> >?>?for driving
> >?>?such a device?
> >?>?
> >?>?Working on it (at th emoment using an ARM, I don't think a 16F or
> >?> 18F?will be enough).
> >?
> >?Really? From the last time I worked on a T6963 based LCD, the timing
> >?requirements were not so bad that it couldn't be handled by a parallel
> >?loaded shift register IIRC.
> >?
> >?Maybe we've found a job for a high speed dsPIC!
>
> I think the speed concerns are not with the hardware interface per se
> but with character drawing speed and the graphics kernel
> math/calculation speed. A monochrome 320 x 200 display requires 8K
> display data bytes. A screen update from a local buffer involves
> transferring 8KB so any delays in wrting to the hardware add up
> quickly. The hardware interface speed (LCD controller and I/O read
> write speed) and data transfer rate can be significant. Add to that any
> time required for calculating bitmaps for fonts, line drawing, etc. and
> the display update rate can be perceived as quite slow unless you
> minimize the delays.
>
> I recently completed a project with a 320 x 240, 16 gray level display
> connected to the data bus of a 29MHz Rabbit 2000 CPU and it was only
> marginally fast enough (as expressed by the client). It took about 200
> mS to update the screen via a buffer transfer from Rabbit to LCD frame
> memory due to speed restrictions of the LCD controller and the fact
> that 16KB of data needed to be transferred.

Just to be clear, you were updating the LCD directly from the Rabbit?
I wal always thinking the way to do this is with dual buffered RAM
where the data updating the LCD was latched, and during the transfer
of the latched data, the CPU could write the RAM at full speed.

But I never finished implementing it, so no benchmarks as to performance
were ever done.

> I'm getting ready to do a 320 x 240 color TFT display for a medical
> project and we're planning to use a 40MHz+ ARM7 CPU just because of the
> graphics requirements.

Should there not be a LCD controller that can handle getting stuff to the
display? Just curious.

Actually it's not really a debate. All of us agree that
prototyping boards are useful for jump starting development.
We all agree that a modular format affords flexibility when
doing development. We all agree that choosing the right connector
is a critical aspect of developing the proper interface.

The only disagreement was whether it's more effective to mount
a bunch of common development items in some type of container or
if having a box of loose daughterboards works effectively.

As for the on-chip debug specification for 18F and dsPIC and
ICD2 communication protocol, I have raised the question in
the Microchip Forum ICD2 section. So far there is no response
from Microchip forum moderators. They choose to be silent again.
;-( It seems that this is a difficult question for them.

According to some forum posts, there will be new debug specification
for some new high end chips, will it be JTAG or similar?

Here are some links of ICD2 clones in China. The price
is for reference only. The information is only to prove
ICD2 clone can be made quite cheap.

Take note that shipment to outside of China by Fedex or
Postal Office EMS is quite expensive. It is a bit strange
but the oversea telephone charges and postages are much
more expensive in China than in Singapore even though
Singapore's average GNI is about 19 times of China
(Worldbank 2003 GNI per capita data: USA US$41400,
Singapore US$24220, China US$1290, India US$620).

Retail price of ICD2 is about RMB800 (US$100) or RMB1000 (US$125)
with a demo board. The bulk price can be as low as US$60. Shipment
charge unknown. However my understanding from some Chinese
forum posts is that they are not allowed to sell outside
of Chinese market.

The extend of delivery is quite good (usb cable, serial
cable, 6-pin ICD2 cable, 28pin/40pin debug header,
9V supply and now with promotion a universal program
adapter with a 40-pin ZIF). The problem may be the support
since this is a one-man shop.