I share your pain -- it's very hard to put bread on the table by developing
device programmer software (GUI application and firmware). Tremendous
amounts of time is spend just creating it. Then, since most people expect
upgrades to be free, any additional time you spend on maintaining it for
current and future device support just eats away at your hourly wage.
Easily comes out that you are making large amounts of 'negative money'. :)
I love doing it anyway however -- it's a labor of love for me and great fun.
Since it's so general a problem, I'm curious why someone hasn't come up
with a XML format for describing programming algorithms for the ICSP
chips. Then Microchip would come out with the spec once, it would be
converted once, and those who maintain their own software could import
it into their own system.
It would be fairly complex, I suppose, depending on how the firmware and
software is actually designed.
It could join all the wishlist XML projects like the circuit description
language, device description for ECAD software, etc...
>Hi Tony,
>
>I share your pain -- it's very hard to put bread on the table by developing
>device programmer software (GUI application and firmware). Tremendous
>amounts of time is spend just creating it. Then, since most people expect
>upgrades to be free, any additional time you spend on maintaining it for
>current and future device support just eats away at your hourly wage.
>Easily comes out that you are making large amounts of 'negative money'. :)
>
>I love doing it anyway however -- it's a labor of love for me and great fun.
>
>Best regards,
>
>Ken Pergola
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body
>
>
>
>
>
No matter how easy it will become to maintain a third party device
programmer, it truly is a never-ending project that still requires a lot of
energy for a one-man operation. It is very difficult to anticipate how new
programming specifications will differ from existing ones and they, like
everything else in this world, change over time. Then if you want to
automate testing someone has to spend the time to develop those automated
tests -- it's a lot of work. But like I said before it's also fun and
rewarding.
After the initial sale of the device programmer to the customer, usually no
more income will come in because it's very hard to compete with free device
programmer software/firmware upgrades. 'Everything for free' seems to be the
mantra these days.
Microchip is the lucky one -- at least the development costs of the tools
they produce are basically subsidized by their core business.
But one can also make the argument that without the existence of their
development tools in the first place, they would not be able to sell their
core products either.
I suspect the motivating factors behind programming algorithms involve
internal testing channels (ways to verify the chip's integrity). When a
chip is changed in a significant way internally, the programming
algorithm will probably change as well.
I don't think Microchip cares about programming at all, as long as it
can be done in some manner.
BUT, I also see YOUR side of it. Microchip should warn you 3rd Party
Folks weeks in advance that a new spec is coming, and provide you with a
"test chip" to test it on.
> No matter how easy it will become to maintain a third party device
> programmer, it truly is a never-ending project that still requires a lot of
> energy for a one-man operation. It is very difficult to anticipate how new
> programming specifications will differ from existing ones and they, like
> everything else in this world, change over time. Then if you want to
> automate testing someone has to spend the time to develop those automated
> tests -- it's a lot of work. But like I said before it's also fun and
> rewarding.
>
> After the initial sale of the device programmer to the customer, usually no
> more income will come in because it's very hard to compete with free device
> programmer software/firmware upgrades. 'Everything for free' seems to be the
> mantra these days.
>
> Microchip is the lucky one -- at least the development costs of the tools
> they produce are basically subsidized by their core business.
> But one can also make the argument that without the existence of their
> development tools in the first place, they would not be able to sell their
> core products either.
>
> Regards,
>
> Ken Pergola
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body
>
--
Replies: NOTE-Script, EXE,BAT and COM
files will be rejected by server
--------------
Bob Axtell
PIC Hardware & Firmware Dev http://beam.to/baxtell
1-520-219-2363
> BUT, I also see YOUR side of it. Microchip should warn you 3rd Party
> Folks weeks in advance that a new spec is coming, and provide
> you with a "test chip" to test it on.
About test chips - any news on the availability of 30F's and their
programming specifications?
> Since it's so general a problem, I'm curious why someone
> hasn't come up
> with a XML format for describing programming algorithms for the ICSP
> chips.
The problem is that every now and then Mirochip comes up with something
that is so different that you would need an update of your XML format.
The new thing Tony was complaining about is that they spread the bits of
a single configuration item over different configuration words. No
problem for my programmer because it does not allow you to edit the
configuration word (IMHO that option does not belong in a programmer),
but stil an horrible idea only Mirochip could come up with. I guess they
guy who designed the 12F call format and the 12/16/17/18 numbering
scheme is still active.
> Microchip should warn you 3rd Party Folks weeks in advance that
> a new spec is coming, and provide you with a
> "test chip" to test it on.
Oh, yes, in Microchip's defense, they do give Third Party developers heads
up information and samples.
There's no complaint from me in that department.
I guess my point is that I don't see any viable business model in a third
party programmer.
By the way, how did your portable programmer come out. I think you were
using MMC for storage?
It's interesting that Microchip's PM3 programmer uses MMC or SD for
storage -- it's a nice-looking unit.
On Mon, 9 Feb 2004 23:12:22 -0500, "M. Adam Davis" wrote:
>Since it's so general a problem, I'm curious why someone hasn't come up
>with a XML format for describing programming algorithms for the ICSP
>chips. Then Microchip would come out with the spec once, it would be
>converted once, and those who maintain their own software could import
>it into their own system.
>
>It would be fairly complex, I suppose, depending on how the firmware and
>software is actually designed.
>
>It could join all the wishlist XML projects like the circuit description
>language, device description for ECAD software, etc...
>
I don't know if other CAD packages are taking this route but AutoTRAX
(a new program, not the old Protel Autotrax) at http://www.autotraxeda.com
allows you to output schematics, PCBs, parts and footprints in XML
format. It's a very handy capability to have available.
>The problem is that every now and then Mirochip comes up with something
>that is so different that you would need an update of your XML format.
>The new thing Tony was complaining about is that they spread the bits of
>a single configuration item over different configuration words. No
>problem for my programmer because it does not allow you to edit the
>configuration word (IMHO that option does not belong in a programmer),
>but stil an horrible idea only Mirochip could come up with. I guess they
>guy who designed the 12F call format and the 12/16/17/18 numbering
>scheme is still active.
>
>
>
Good idea Wouter.
My FUSE edit page has grown in leaps and bounds since the 18 series came
out. What's it going to be like 5 years up the track.
I think I might delete all the FUSE editing options which would make the
whole thing a lot easier to maintain. I personally have never used them
and I'm not actually sure who does. They are easy to maintain in the
source code anyway.
Can't large memory arrays be programmed in one hit. Why can't [all] the
PICs just serial in the ROM EEPROM and ID data then hit it with one fat
programming pulse? Then do the FUSE.
> Bob Axtell wrote:
>
>
>> Microchip should warn you 3rd Party Folks weeks in advance that
>> a new spec is coming, and provide you with a
>> "test chip" to test it on.
>
> Oh, yes, in Microchip's defense, they do give Third Party developers
heads
> up information and samples.
> There's no complaint from me in that department.
> I guess my point is that I don't see any viable business model in a third
> party programmer.
I decided it was not a heavy market, either, as I was too busy with
PAYING stuff.
> By the way, how did your portable programmer come out. I think you were
> using MMC for storage?
> It's interesting that Microchip's PM3 programmer uses MMC or SD for
> storage -- it's a nice-looking unit.
I got it to work, but decided NOT to pursue it commercially. There are
too many GOOD PIC programming tools out there.
I like Tony Nixon's K128. When he gets a ICSP connector on it, and
switches to the "USB B" connector, and beefs up the +13V a little, it'll
be a winner.
PM3?? Er... well.. ya know I'm only a 70 miles south of Chandler... in
Tucson.... <g>
> I like your web site Bob -- thanks for sharing!
Its pretty limp right now... Gotta lot more stuff to show. Dfropped my
good digital camera, my other one takes terrible shots...
Replies: NOTE-Script, EXE,BAT and COM
files will be rejected by server
--------------
Bob Axtell
PIC Hardware & Firmware Dev http://beam.to/baxtell
1-520-219-2363
> The dsPIC30F Programmer's Reference Manual (DS70030E) is not a programming
> specification document.
>
> Last I was told, the dsPIC programming specifications are not ready for
> release yet, but will be posted on the web site when they are ready.
>
> So we will all probably see them under PROGRAMMING SPECIFICATIONS.
>
OOPS ! !
Thank you very much for that info Ken, it is much appreciated. Besides I
can't
afford to offend Wouter at this point in time since I'm going to try to get
him to
sell me a Wisp628. Maby I need to get that order in before he catches up on
his e-mail.
> I like Tony Nixon's K128. When he gets a ICSP connector on it, and
> switches to the "USB B" connector, and beefs up the +13V a little, it'll
> be a winner.
Just finished the new PCB layout. Has USB B and 5 pin ICSP connector.
Not sure about beefing up the 13V rail and keeping it uncomplicated. At
the moment it's just a simple voltage tripler generated by the 16F628
hardware.
Tony Nixon wrote:
> Bob Axtell wrote:
>
>> I like Tony Nixon's K128. When he gets a ICSP connector on it, and
>> switches to the "USB B" connector, and beefs up the +13V a little, it'll
>> be a winner.
>
>
> Just finished the new PCB layout. Has USB B and 5 pin ICSP connector.
> Not sure about beefing up the 13V rail and keeping it uncomplicated. At
> the moment it's just a simple voltage tripler generated by the 16F628
> hardware.
I was only commenting about beefing the +13V as to being able to use it
for UV PROM processors as well. Just needs slightly more 13V current
(but not much). ICSP isn't very useful for the UV parts.
I like this thing more everyday, Tony. Its a winner.
--Bob
--
Replies: NOTE-Script, EXE,BAT and COM
files will be rejected by server
--------------
Bob Axtell
PIC Hardware & Firmware Dev http://beam.to/baxtell
1-520-219-2363
> I was only commenting about beefing the +13V as to being able
> to use it for UV PROM processors as well. Just needs slightly more 13V
current
> (but not much). ICSP isn't very useful for the UV parts.
?? Last time I looked into the specs EPROM PIC programming required
100mA or so. Not something you'd easiliy get from a charge pump!
> Just finished the new PCB layout. Has USB B and 5 pin ICSP connector.
> Not sure about beefing up the 13V rail and keeping it
> uncomplicated. At
> the moment it's just a simple voltage tripler generated by the 16F628
> hardware.
I think that might fail on a 16C84 when the USB power is at the lowest
level allowed by the spec.
Ken Pergola wrote:
> The dsPIC30F Programmer's Reference Manual (DS70030E) is not a
> programming specification document.
>
> Last I was told, the dsPIC programming specifications are not ready
> for release yet, but will be posted on the web site when they are
> ready.
>
> So we will all probably see them under PROGRAMMING SPECIFICATIONS.
Right. The document has "Programming Specification" in its name.
By the way, the programming algorithm for the dsPICs is totally different
from anything before it. Unfortunately they also changed the pinout so that
most existing programmers won't work.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>I think that might fail on a 16C84 when the USB power is at the lowest
>level allowed by the spec.
>
>
>
K128 only programs chips from the chipinfo file that are listed as F series.
regards
Tony
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> > I think that might fail on a 16C84 when the USB power is at
> > the lowest level allowed by the spec.
> K128 only programs chips from the chipinfo file that are
> listed as F series.
OK, disregard the 16C84. The level at which a 16F84(A) will switch to
programming mode is specified as 12 .. 14 Volt, which I interpret as 'no
chip will enter below 12, all chips will enter below 14'. So you need 14
for reliable programming, which is more than 3 times the lowest voltage
you can get from USB (plus you will have some loss in the diodes). In
practice this won't be a big problem since most people use powered hubs,
and most chips enter prog mode below 13 V, but IMHO it is still a design
flaw. Note that my own Wisp628 is not entirely off the hook on this
aspect either.
>OK, disregard the 16C84. The level at which a 16F84(A) will switch to
>programming mode is specified as 12 .. 14 Volt, which I interpret as 'no
>chip will enter below 12, all chips will enter below 14'. So you need 14
>for reliable programming, which is more than 3 times the lowest voltage
>you can get from USB (plus you will have some loss in the diodes). In
>practice this won't be a big problem since most people use powered hubs,
>and most chips enter prog mode below 13 V, but IMHO it is still a design
>flaw. Note that my own Wisp628 is not entirely off the hook on this
>aspect either.
>
>
>
Yes, the F84 looks similar to the C84 in that regard. I haven't had
problems yet, but if I do I will remove it from the K128 list. The other
F series look like VCC + 3.5V for VPP as a minimum (or there abouts).
regards
Tony
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>From: Tony Nixon <KILLspamTony.NixonspamBeGoneENG.MONASH.EDU.AU>
>
>GND
>VCC
>CLK
>DAT
>VPP
>
>I just do the code and layout, KitsRus sell the hardware. You would have
>to check with them re cable.
>
>regards
>
>Tony
> ...Just when you think you are getting on top of the new chips and what
> appears to be a new programming algorithm for each...
Hi Tony,
Take a look at the PIC18FX410/X490 programming specification -- this caught
me off guard.
If the programming specification document for the PIC18FX410/X490 flash
PICmicros is totally correct, then the electrical characteristics have been
changed for this particular group of PIC18F devices (I have not totally
reviewed the programming algorithm yet) versus what seemed to be the norm
for all other PIC18F devices.
I have an e-mail into Microchip on this one just to confirm this:
* High-Voltage Programming Voltage on MCLR/VPP has been narrowed: 10 to 12
volts WRTG (with respect to ground).
(all other PIC18Fs: 9 to 13.25 volts WRTG)
* Programming Current on MCLR/VPP: 100 milliamps
(I hope they meant microamps as most others were around 300 microamps)
* Supply Voltage During Programming [CHIP ERASE] lowered: min = 2.75 V WRTG
(Excellent news if this really means a minimum of 4.5 V is not needed for
a complete bulk erase)
This really seems to drive home the point for me that any PICmicro
programmer really needs a variable Vpp supply under firmware control in
order to be one step ahead of the specifications: inexpensive digital pot
and adjustable LDO regulator.
mitvma.mit.edu with SET PICList DIGEST in the body
