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

Exact match. Not showing close matches.
PICList Thread
'[PIC] Has anyone developed a programmer for 16F193'
2010\12\31@190741 by Byron Jeff

flavicon
face
I'm in the process of working through a USB serial port based code dumper
for the the 16F193X/18F182X series of chips. So far I'm having pretty good
luck with the PL2303 based USB to serial converter that I got a hold of.
I'm using a current version of pyserial to drive the DTR, RTS, and TX
through a zener voltage conditioner and HCT04 inverters. CTS reads fine as
feedback.

I'm interested in working with the new LVP setup that Microchip has put on
the chip. The basic idea is to clock in a "programming key" while MCLR is
held at Vil. The key is a 32 bit pattern that converts to ASCII as "MCHP".

The progspec specifies that the key needs to be clocked in LSB first. The
one piece of code that I could find that seemed to clock in this pattern is
located here:

http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/PiratePICprog/OpenProg/progP16.cpp?r=311

>From lines 688 to 693. The comment and the code both indicate that the key
is in fact clocked LSB first.

I've tested my code code with other PICs (16F88 in particular) and it does
properly clock and read. In addition I went ahead and rigged a HVP setup
for the 16F193X/12F182X parts and it goes into programming mode and reads
the chip properly. So I do have a path to continue getting the dumper done.

However despite all my efforts, I've had no luck in getting the key to
unlock programming mode. The progspec's diagram for the key indicates that there are 33 clocks for the key, but the description indicates that 32 bits
are clocked in. I tried both with no luck.

So I ask: has anyone developed code for LVP programming of these parts?
Does the programming key work? Any answers for the magic incantation to get
programming going under LVP would be appreciated.

Thanks in advance. And Happy New Year to everyone!

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef


'[PIC] Has anyone developed a programmer for 16F193'
2011\01\01@085409 by Olin Lathrop
face picon face
Byron Jeff wrote:
> I'm in the process of working through a USB serial port based code
> dumper
> for the the 16F193X/18F182X series of chips.

The 16F1826 specifically is on my list.  Maybe it will happen this weekend.
It took a while to get samples in, and I sortof forgot about it.

> I'm interested in working with the new LVP setup that Microchip has
> put on
> the chip. The basic idea is to clock in a "programming key" while
> MCLR is
> held at Vil. The key is a 32 bit pattern that converts to ASCII as
> "MCHP".

I haven't read the programming spec yet, but that sounds a lot like the same
procedure as the 3.3V parts.  Those don't allow MCLR to be raised to a high
voltage, so clocking in the key is the only means to enter programming mode..
So far that has always workes as expected for me.  I did notice that the key
is not the same for all parts.

> The progspec specifies that the key needs to be clocked in LSB first.

Microchip's Programming Obfuscation Division regularly dreams up new and
incompatible programming schemes, but so far they have all been LSB first.
You never know what the talented engineers at POD will come up with next,
but MSB first would really surprise me.

> However despite all my efforts, I've had no luck in getting the key to
> unlock programming mode.

Usually PGC and PGD have to be held just right while MCLR is blipped just
right before the key can be clocked in.  Vdd might also require special
handling.  Check the spec and make sure your code does that.

> So I ask: has anyone developed code for LVP programming of these
> parts?

Not for those parts just yet, but I have for other parts that use a magic
key sequence to enter programming mode.  You can look at my code if you
want.  Install the Development Software release from
http://www.embedinc.com/picprg/sw.htm, then look around in the file SOURCE >
PICPRG > PICPRG_OP.INS.ASPIC.  Several magic key reset algorithms are
implemented in there.


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

2011\01\01@121214 by Byron Jeff

flavicon
face
On Sat, Jan 01, 2011 at 08:55:05AM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > I'm in the process of working through a USB serial port based code
> > dumper
> > for the the 16F193X/12F182X series of chips.
>
> The 16F1826 specifically is on my list.  Maybe it will happen this weekend.
> It took a while to get samples in, and I sortof forgot about it.

That's good. It'll be good to see if you have any problems.

>
> > I'm interested in working with the new LVP setup that Microchip has
> > put on
> > the chip. The basic idea is to clock in a "programming key" while
> > MCLR is
> > held at Vil. The key is a 32 bit pattern that converts to ASCII as
> > "MCHP".

[Snippage]

> > However despite all my efforts, I've had no luck in getting the key to
> > unlock programming mode.
>
> Usually PGC and PGD have to be held just right while MCLR is blipped just
> right before the key can be clocked in.  Vdd might also require special
> handling.  Check the spec and make sure your code does that.

I've poured over the progspec. There doesn't seem to be anything special.
There's no requirement that MCLR be blipped at all, though I tested it
both ways. I start the process with PGC and PGD both at Vil. I tested
it both with blipping MCLR and not. Also while there is a minimum time
specified between MCLR's falling edge and the start of clocking the key
(of 250 uS), there is no maximum time specified.
So from everything that I've gathered so far, there should be no problem
with starting the part with MCLR, PGD, and PGC all at Vil, waiting an
arbitrary amount of time, then clocking in the key.

As I said in my original post, figures 8-9 and 8-10 of the progspec shows
the key clocked in with 33 clocks. But it's only a 32 bit key. So I'm
trying to figure out if I need to clock that extra clock or not (as the
text for LVP entry does not discuss the extra clock in the description).
I did test both with 32 clocks and 33 clocks, and got no joy with either.

{Quote hidden}

Will do. Thanks for the pointer.

BAJ

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

2011\01\01@123356 by Byron Jeff

flavicon
face
On Sat, Jan 01, 2011 at 08:55:05AM -0500, Olin Lathrop wrote:
> Usually PGC and PGD have to be held just right while MCLR is blipped just
> right before the key can be clocked in.  Vdd might also require special
> handling.  Check the spec and make sure your code does that.

The spec for the 16F193X is significantly different than the 18J series
which I took the time to look up.

I have a preliminary version of the programming specification for the
16F193X parts. Let me get the latest copy and double check...

Done. It's still the same as the spec I have.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\01@125537 by PICdude

flavicon
face
I'm using the 16F1936 a lot nowadays, so that would be nice to see...  should you make it a commercial product, that is.

Curious... since you're developing a product, why not use Microchip's MCP2200?

HNY,
-Neil.



Quoting Byron Jeff <spam_OUTbyronjeffTakeThisOuTspammail.clayton.edu>:

> I'm in the process of working through a USB serial port based code dumper
> for the the 16F193X/18F182X series of chips. So far I'm having pretty good
> luck with the PL2303 based USB to serial converter that I got a hold of.
> I'm using a current version of pyserial to drive the DTR, RTS, and TX
> through a zener voltage conditioner and HCT04 inverters. CTS reads fine as
> feedback.
>
> ...

2011\01\01@133520 by Byron Jeff

flavicon
face
On Sat, Jan 01, 2011 at 12:55:36PM -0500, PICdude wrote:
> I'm using the 16F1936 a lot nowadays, so that would be nice to see...  
> should you make it a commercial product, that is.

>
> Curious... since you're developing a product, why not use Microchip's
> MCP2200?

I'm not developing a product. I'm just trying to continue to support a
hobbyist community that have been using programmers like my Trivial LVP
Pic programmer over the years.

With the death of parallel ports, and to a large extent serial ports on PCs, there's no out of the box interface that can be driven in software on a PC.

So this is my latest effort in the continual quest to find a way out of the
catch-22 of needing a programmer to program a PIC with a bootloader, so
that a programmer is not required for development. And finding a way to do
it with off the shelf components, which is why the MCP2200 isn't on my
radar. Also it doesn't come in DIP, which most hobbyist still need to get
started. Finally I'm unsure if there is a specific Linux driver for the
chip.

The standard USB to serial cable serves the dual purpose as the driver for
the "code dumper" and as the primary programming interface for the
bootloader. So it gets used all the time during development in my system.
They are cheap, available off the shelf, and have standard drivers for
every operating system.
This is a specific design for building out of junkbox parts quickly,
letting it do it's job of dumping a bootloader on the chip, and getting out
of the way.

I'm in good shape because it works with HVP. Just curious about why LVP is
having so many problems.

I did see one thing in the BusPirate programming code. There is definitely
a 33rd clock. I'm going to do some more testing with that presumption and
see if I can get it going.

BAJ

{Quote hidden}

> -

2011\01\01@134916 by Mark Rages

face picon face
On Sat, Jan 1, 2011 at 12:50 PM, Byron Jeff <byronjeffspamKILLspammail.clayton.edu> wrote:
{Quote hidden}

The FTDI cable (http://www.sparkfun.com/products/9717) has bitbang
mode usable with libfti (libftdi.sf.net)
http://www.intra2net.com/en/developer/libftdi/

This gives you power, ground, and four pins of general purpose I/O.
You can write multiple I/O states and the chip will clock them out
using the async baudrate clock.  So it is not as slow as you might
expect, since you can clock a lot of transitions in one USB transfer.

It has been one of my want-to-do projects to write a LVP PIC
programmer that uses this cable, probably adapting one of the other
bit-twiddling PIC programmers to do so.  Acually, a bit-twiddling
programmer could have backends for parallel port, this cable, bus
pirate, goodFET, the FTDI-based JTAGger tools, Arduino etc.

The FTDI cable is useful for async serial too.

PS. The MCP2200 uses standard ACM driver which is stock in Linux for
some time now.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
.....markragesKILLspamspam.....midwesttelecine.co

2011\01\01@142705 by Jan-Erik Soderholm

face picon face
Byron Jeff wrote 2011-01-01 19:50:
> On Sat, Jan 01, 2011 at 12:55:36PM -0500, PICdude wrote:
>
>> Curious... since you're developing a product, why not use Microchip's
>> MCP2200?
>
> ...Finally I'm unsure if there is a specific Linux driver for the
> chip.

You could always check what the "MCP2200 Linux Driver Readme" says.
http://ww1.microchip.com/downloads/en/DeviceDoc/mcp2200_linux_driver_readme..txt

Jan-Erik

2011\01\01@172235 by Michael Watterson

face picon face
On 01/01/2011 18:50, Byron Jeff wrote:
> With the death of parallel ports, and to a large extent serial ports on PCs,
> there's no out of the box interface that can be driven in software on a PC.
yes there is. It's USB,

It's trivial to write program for PIC in JAL to use existing USB HID, Storage or Serial Drivers.

As long as you are doing data and not "bit-banging" any language/program can use a virtual serial port provided by a USB interface.

Then the PIC can use I2C,  Serial, Parallel, PATA, ICSP and many other interfaces. An 18F2550 or 18F4550 is a good one to start playing with.

In fact the Pickit 2 is this using USB HID. You can use it as a logic analyser, TTL serial adaptor or ICSP. You can even put your own firmware on it. Quite inexpensive

2011\01\01@174001 by Byron Jeff

flavicon
face
On Sat, Jan 01, 2011 at 05:22:22PM -0500, Michael Watterson wrote:
> On 01/01/2011 18:50, Byron Jeff wrote:
> > With the death of parallel ports, and to a large extent serial ports on PCs,
> > there's no out of the box interface that can be driven in software on a PC.
> yes there is. It's USB,
>
> It's trivial to write program for PIC in JAL to use existing USB HID,
> Storage or Serial Drivers.

But therein lies the catch 22 that I refered to. To program a PIC in JAL
you need a programmer of some sort. PIC, unlike some other chips in the
past, do not have a built in bootloader, so that they can be programmed out
of the tube with a serial interface.

The legacy ports always gave you pins that you could wiggle in software.
USB does not without attaching something else to it. The cheapest and most
ubiquitous device nowadays for that is a USB serial interface.

>
> As long as you are doing data and not "bit-banging" any language/program
> can use a virtual serial port provided by a USB interface.
>
> Then the PIC can use I2C,  Serial, Parallel, PATA, ICSP and many other
> interfaces. An 18F2550 or 18F4550 is a good one to start playing with.

But how do you program it? I know the typical answer to this is "buy a
programmer". But if you're only going to use it once in a blue moon,
because the primary mode of development is a bootloader, it's not as simple
a decision as you may think.

>
> In fact the Pickit 2 is this using USB HID. You can use it as a logic
> analyser, TTL serial adaptor or ICSP. You can even put your own firmware
> on it. Quite inexpensive.

Exactly my point. You need a programmer in order to program the chip.

I know I've been gone awhile, but I was pretty sure everyone here knew my
thoughts on the development process. There are tons of threads going back
several years on this particular discussion.

Modern PICs can program themselves. No additional programmer required. But
it requires software to get into the part so that it can program itself.

Catch-22.

My Trivial LVP here:

http://www.finitesite.com/d3jsys
always served that purpose for me, and quite a few other hobbyist. But the
death of parallel ports (or at least integrated ones) killed this design.
I'm searching for a replacement.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\01@184455 by Olin Lathrop

face picon face
Byron Jeff wrote:
> But how do you program it? I know the typical answer to this is "buy a
> programmer".

Exactly.  It seems like you're going a long way to avoid getting a
programmer.  Do you realize a fully compliant programmer is now available in
singles for only $20
(http://www.microchipdirect.com/ProductSearch.aspx?Keywords=TEMLP001)?
That's cheaper than I sell singles on my own web site.  I'll make them
available at subtantial discount if you want to outfit a whole lab or get
one for every student in a class.  Even before any educational discount,
it's already a lot less money than any book the student will have to buy for
a class.

The LProg only handles the PICs that can enter program mode with the unlock
sequence and don't require high voltage on Vpp, but there are plenty of
those to chose from and that shouldn't be much of a constraint if you're a
hobbyist or student.

Hopefully it will do the 16F182x subfamily soon.  I'm digging thru the
normal high voltage programming algorithm now, and see that the POD has been
busy.  It's mostly the same, but just different enough to require more cases
to be added in a few places.  After I get the 16F182x working with normal
HVP on the USBProg, I'll try to add support to the LProg with LVP.

> But if you're only going to use it once in a blue moon,
> because the primary mode of development is a bootloader, it's not as
> simple a decision as you may think.

But you're only using the programmer once in a blue moon because it kinda
sucks, being a "dumper" as you call it.  Think of the reverse.  If you
already had a programmer then you wouldn't have to hassle with a bootloader
at all.

If your project can do with 100mA Vdd, then you can even program and run in
a single command that takes a few seconds.


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

2011\01\01@185243 by PICdude

flavicon
face
That actually explains a lot now.  I only suggested the MCP2200 as it  too is a USB-Serial converter, but was not aware of the thru-hole  requirement.  From what I remember of the MCP2200 when I read up on it  a couple months back, it does not require any special driver for Linux  other than the built-in drivers (possibly HID, but don't hold me to  that).

I'm fully on board now, as I seem to get asked regularly what to use  to get started with PIC programming, and I always recommend the  Pickit2, but many aren't even willing to pay $35 to get their feet  wet, and would rather put in the time rather than the extra bucks to  get a programmer.  From your website, it seems your trivial LVP would  fit the bill very nicely.  Looking forward to seeing the outcome.

Cheers,
-Neil.



Quoting Byron Jeff <EraseMEbyronjeffspam_OUTspamTakeThisOuTmail.clayton.edu>:
{Quote hidden}

>

2011\01\02@043514 by Michael Watterson

face picon face
On 01/01/2011 22:55, Byron Jeff wrote:
> But how do you program it? I know the typical answer to this is "buy a
> programmer". But if you're only going to use it once in a blue moon,
> because the primary mode of development is a bootloader, it's not as simple
> a decision as you may think.
A soldering iron can cost lest than a PicKit2.

I've built several low parts count programmers/adaptors for parallel (JTag) and serial (RDS data, ISOcard reader, PIC ICSP), but indeed these things are pointless really, a PIC with USB slave port built in in as cheap, less time to assemble on stripboard and more reliable. To ANY embedded CPU development you need a Computer, soldering iron, Magnifying lamp, various other stuff.. Bench PSU, multimeter and Scope recommended. The extra cost of a PicKit2 is small.

It's a simple decision. The Pickit2 is about 25 euro. You can use it for other stuff as well as programming a PIC.  Also on  Linux or Windows accurately "bit twiddling" serial port pins can't easily be done fast at any accuracy without writing a device driver. You can do it faster and more reliably on DOS on a 33MHz 486 than on modern 1.6GHz PC even if it has a serial port. Or indeed on a 16F877A or 18F4550.

IMO a bootloader is only for projects where the user rather than the developer is to change code. For well designed development with parts pre simulated and good design I see little or no advantage to a bootloader over the ICSP.

2011\01\02@044248 by Michael Watterson

face picon face
On 01/01/2011 23:45, Olin Lathrop wrote:
{Quote hidden}

Olin speaks great sense here.

If I was doing production programming I'd not recommend the Pickit2. It and other budget programmers are for people that want to dabble and don't want to spend money.

As I had my own home made ICSP programmer (using VP=12V) and serial port bitbanging for several years, I bought the Pickit2 at recommendation of the list here as I needed 3.3V prog for 18FxxJxx family. I wish I had bought it sooner. It was actually cheaper on Microchip site than clones, but delivery was 3 months. so I bought the clone from Sure Electronics (it matches Microchip published schematic) and it happily loaded the latest firmware version from Microchip. You can pay MORE in the Retail High street for a dumb USB to Serial Adaptor

2011\01\02@110451 by Byron Jeff

flavicon
face
On Sat, Jan 01, 2011 at 06:52:41PM -0500, PICdude wrote:
> That actually explains a lot now.  I only suggested the MCP2200 as it  
> too is a USB-Serial converter, but was not aware of the thru-hole  
> requirement.  From what I remember of the MCP2200 when I read up on it  
> a couple months back, it does not require any special driver for Linux  
> other than the built-in drivers (possibly HID, but don't hold me to  
> that).

>From the page you gave me to read, I believe that is correct. Plug it in
and it works.

> I'm fully on board now, as I seem to get asked regularly what to use  
> to get started with PIC programming, and I always recommend the  
> Pickit2, but many aren't even willing to pay $35 to get their feet  
> wet, and would rather put in the time rather than the extra bucks to  
> get a programmer.  From your website, it seems your trivial LVP would  
> fit the bill very nicely.  Looking forward to seeing the outcome.

It's a bit more than just the $35 for the programmer. If ICSP programming
was my primary mode of development, it would be a great buy. I actually
have access to a PicKit 2 at work. For years now from Wouter's WLoader for
the 16F877 to currently Frank Sargent's Pikme bootloader, which he
originally wrote for the 16F819, I updated for the 16F88, and an currently
updating to the 16F193X series, I been developing with bootloaders. I'm
attracted to the choice of interface and the backchannel debugger. Without
getting into yet another argument about the best way to do development,
personally I find I'm most productive with bootloaders.

So while a programmer is a requirement, it's a minimal one. I also believe
that much of this driven by being a Linux guy in a Windows world. While the
PicKit 2 finally has OK Linux support, the PicKit 3 does not. And support
always drags behind the requires Windows support.

Finally I work in an academic environment with a bunch of students. Buying
a lab full of programmers for development doesn't make much sense.
Still all in all I miss legacy ports on both laptops and desktops. The
interface was embedded and not other support devices were required for
interfacing.

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\02@120811 by Byron Jeff

flavicon
face
On Sun, Jan 02, 2011 at 04:42:35AM -0500, Michael Watterson wrote:
{Quote hidden}

Gentlemen,

Trust me when I say that there's more to the Universe than you show.

I've never been a fan of programmers, ICSP or otherwise. The required
interface has always been restrictive, requiring a minimum of 3 I/O pins
(and until recently 4 with LVP) to operate. A developer is either stuck
impacting their target to accomodate ICSP or having to pull the chip in
order to program it, which really sucks.

I thank Wouter for spoiling me rotten. With both WLoader, with its one pin
half duplex interface, and ZPL and its virtual zero pin interface, the
programming interface becomes a single pin, or my choice, which usually a
pin that's out the way, instead of the top two pins of PORTB, possibly the
middle of PORTB, and MCLR, which is always shared with an input. Frank
Sargent followed a similar route with his PikMe bootloader, making it
bitbanged input only. For example on the 16F1939, MCLR is shared with
PORTE3 as an input. The top pin of the last port is completely out of the
way.

Take a read of Wouter's ZPL design document for a more detailed discussion.
I took the liberty of putting a copy on my site:

http://kahuna.clayton.edu/byron/zpl.pdf

Even though that was 8 years ago, all of his points are still valid:

- Chips are getting faster with more memory
- I/O space and peripheral usage is at a premium
- A transparent bootloader using simple interface hardware can be a
 useful development environment.

Now it's even better with embedded precision oscillators and actual I/O
being shared on the MCLR pin. The programmer to the target becomes
essentially a 2 wire interface that's completely out of the way of the
application. And the single real cost, the program memory usage, is the
real cost that can be easily absorbed. The 16F1939 I'm using now has 16K
words of program memory. A good bootloader will take up about 200 of those
words.

The final item is that no matter what type programmer you bring to the
table, they are not going to be available off the shelf, and they only
serve that one singular purpose of programming PICs. Even though they are
similar in price, USB to serial converters are easily available, and they
can serve more purposes than just programming PICs. It may even be an item
that a new developer already has.

It's a viable development method, and there are valid reasons for pursuing
it. ICSP just cannot ever be as transparent as a bootloader can be.

BAJ



-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\02@122559 by PICdude

flavicon
face
Quoting Michael Watterson <mikespamspam_OUTradioway.org>:

> Olin speaks great sense here.
>
> If I was doing production programming I'd ...

But this is straying off the main point, isn't it?  Byron's programmer  is targeting individuals who want to get their feet wet before  investing in any equipment, or need a one-time (or thereabouts)  programmer for some project they found on the web.  I've seen this a  lot recently -- where a tinkerer has a soldering iron and breadboard,  etc, but wants to implement some PIC project and being able to spend a  few bucks on a chip and wire up a Q&D programmer on a breadboard would  be great.  The other point being that if someone does not have a PIC  programmer they can't build a programmer that requires programming a  PIC.

I'm in a similar situation with other chips currently.  Been  investigating AVR's, MSP430, Renesas and other chips and don't want to  buy a programmer for each, just to evaluate.  Atmel actually threw a  freebie AVR Dragon at me, but I can't get the thing to work right.   However, I found a post where someone used a Pickit2 to program AVR's  and it worked!  If I had not, I'd be looking for a similar  hobbyist-level programmer I could put together on a breadboard for  short-term use.

Cheers,
-Neil.

2011\01\02@125101 by PICdude

flavicon
face
Quoting Byron Jeff <@spam@byronjeffKILLspamspammail.clayton.edu>:
>
> Finally I work in an academic environment with a bunch of students. Buying
> a lab full of programmers for development doesn't make much sense.

FWIW, for a high-school that I deal with regularly, I pointed out the  MSP430 launchpad deal as a good way to get started for cheap.


> Still all in all I miss legacy ports on both laptops and desktops. The
> interface was embedded and not other support devices were required for
> interfacing.

Agreed!  I keep an old laptop (Thinkpad 600X) and an mini-ITX mobo  with parallel ports laying around, and when the going gets tough (or  complicated), there's nothing like sticking some wires into a parallel  port and bit-banging a Q&D interface.

Cheers,
-Neil.

2011\01\02@130901 by Olin Lathrop

face picon face
Byron Jeff wrote:
> Finally I work in an academic environment with a bunch of students.
> Buying a lab full of programmers for development doesn't make much
> sense.

Really?  As I said, I'd be willing to make a bunch of LProgs available to
you (or anyone else in a legitimate educational setting) for a substatial
discount.  Even at full retail 20 LProgs is only $400, which has got to be a
small fraction of the cost of the rest of the lab equipment.  With the
educational discount that would be $280 ($14 each).


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

2011\01\02@144605 by Byron Jeff

flavicon
face
On Sun, Jan 02, 2011 at 01:09:57PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > Finally I work in an academic environment with a bunch of students.
> > Buying a lab full of programmers for development doesn't make much
> > sense.
>
> Really?  As I said, I'd be willing to make a bunch of LProgs available to
> you (or anyone else in a legitimate educational setting) for a substatial
> discount.  Even at full retail 20 LProgs is only $400, which has got to be a
> small fraction of the cost of the rest of the lab equipment.  With the
> educational discount that would be $280 ($14 each).

I didn't say cost Olin. It doesn't make much sense when chips can program
themselves.

I have a networking lab. We have a lab full of USB to serial cables to talk
to the routers. They can trivially be repurposed for PIC development.

Also LProgs are limited to the type of chips they can program, as are the
cheap Microchip offerings.

Finally, you have meticulously avoided discussing my point about having to
manage the ICSP interface to PGD, PGC, and MCLR. With a bootloader, the
only item the target requires is a high value pulldown resistor on an out
of the way port pin. PortB on any part becomes completely free for
development without any additional management.

I'm trying to comprehend why my discussion of bootloaders seems to
invalidate traditional programmers and causes these circular discussions.
Especially when functioning in a non Windows environment, programmers are
not end all and be all of development as the support tools are limited.

It's not just about cost. It's about simplicity and versitility too.

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\02@160756 by Dave Tweed

face
flavicon
face
Byron Jeff  wrote:
> I'm trying to comprehend why my discussion of bootloaders seems to
> invalidate traditional programmers and causes these circular discussions.
> Especially when functioning in a non Windows environment, programmers are
> not end all and be all of development as the support tools are limited.
>
> It's not just about cost. It's about simplicity and versitility too.

I must be missing something here. Don't you need a programmer to get a
bootloader into a chip? Both initially, and after you've bricked the
bootloader because of an application error.

And don't most bootloaders also require "support tools" on the development
machine? I don't see an advantage either way there.

And in my experience, bootloaders don't generally support any level of
interactive debugging. (But then, a lot of 3rd-party programmers don't,
either.)

Finally, a bootloader always imposes constraints on the application code
that you don't have when using a programmer. At the very least, it occupies
some of the available program memory, and there needs to be a way to select
between running the bootloader and running the application (which has to
work even if the application is buggy). Even Wouter's ZPL imposes a 25-ms
delay on application start-up.

Don't get me wrong -- bootloaders definitely have their place in applications
that require a field-upgrade capability, and I've certainly written my share
of them on several different processor architectures. But I really don't see
the advantage in a general-purpose development workflow.

-- Dave Twee

2011\01\02@163900 by Lyle Hazelwood

picon face
All valid points on both sides of the fence.

I like my PicKit2, and I'm still learning some of it's debugging abilities.

I became a great fan of bootloaders when I started working in the
Midibox community.

Since the "end product" sits in a tightly packed 19" rack with a
gajillion wires attached,
being able to dump a new program by using System Exclusive messages is
a HUGE advantage,
as well as being able to store various versions and apps as SysEx
files and send them with just
a mouse click from my non-supported OS. (Amiga)

True that I cannot develop code on the Amiga, but it is the center of
my Midi studio, and the
bootloader lets it remain there comfortably.

LyleHaz

2011\01\02@170345 by Byron Jeff

flavicon
face
On Sun, Jan 02, 2011 at 04:07:55PM -0500, Dave Tweed wrote:
> Byron Jeff  wrote:
> > I'm trying to comprehend why my discussion of bootloaders seems to
> > invalidate traditional programmers and causes these circular discussions.
> > Especially when functioning in a non Windows environment, programmers are
> > not end all and be all of development as the support tools are limited.
> >
> > It's not just about cost. It's about simplicity and versitility too.
>
> I must be missing something here. Don't you need a programmer to get a
> bootloader into a chip? Both initially, and after you've bricked the
> bootloader because of an application error.

Yes initially. I've never bricked a bootloader. And if one is really
concerned about it, virtually all PICs in production have the ability to
code protect a "boot" block, specifically designed to protect the
bootloader from being overwritten.

>
> And don't most bootloaders also require "support tools" on the development
> machine? I don't see an advantage either way there.

These support tools are little more than read a hex file and write it to
the serial port. There's absolutely no complexity to it.

>
> And in my experience, bootloaders don't generally support any level of
> interactive debugging. (But then, a lot of 3rd-party programmers don't,
> either.)

Personally that's always been a moot point. Linux guy, remember? Until
MPLAB X is finally in production, there is, nor has there ever been a tool
that natively runs under Linux that facilitied debugging. Even pk2cmd right
now only programs the part, with absolutely no debugging facilities.
Can't miss what you don't have.

A serial interface gives a simple bit banged serial channel that can be
used for debugging. Both linwload, which I used with Wouter's Wloader, and
Frank's pikme bootloader have the ability to start a serial terminal after
loading a file which gives an instant input and debugging interface to the
application. Even better the serial transmit and receive routines of the
bootloader are still available for the application to use. So they don't
even need to be rewritten for the application.
>
> Finally, a bootloader always imposes constraints on the application code
> that you don't have when using a programmer. At the very least, it occupies
> some of the available program memory, and there needs to be a way to select
> between running the bootloader and running the application (which has to
> work even if the application is buggy). Even Wouter's ZPL imposes a 25-ms
> delay on application start-up.

All true. There is a minimal startup delay with any bootloader to ensure
that the bootloader has the opportunity to run before the application
start. The memory constraints have been quite relaxed with modern PICs. As
I stated in another post, I'm working with a 16F1939 with 16K words of
program memory. 200 words for the bootloader will hardly be missed.

If one were really deparate to have immediate application execution, one
could easily dedicate another I/O pin to indicate the switch. But
considering the small amount of time that is lost making that determination
(less than 1 second as you pointed out), no bootloader that I've seen has
taken that route.

>
> Don't get me wrong -- bootloaders definitely have their place in applications
> that require a field-upgrade capability, and I've certainly written my share
> of them on several different processor architectures. But I really don't see
> the advantage in a general-purpose development workflow.

I work in the environment that I've chosen. The fundamental change would be
to work in Windows, and that is a line I have drawn in concrete. It will
not be crossed. And the use of emulators and virtual machines simply isn't
worth the benefit.

Whatever limitations bootloaders present to development, I can live with.
I find them infinitely less annoying than the management of ICSP interface
that is required when using a traditional programmer.

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\02@175656 by Marcel Duchamp

picon face
On 1/2/2011 2:19 PM, Byron Jeff wrote:
>
> I work in the environment that I've chosen.

Good. No problem there.

>The fundamental change would be
> to work in Windows, and that is a line I have drawn in concrete. It will
> not be crossed.

Do you allow your students to use Windows?  I ask with the point in mind that when they graduate, experience with Windows will be what 99% of their future employers will expect.  Yes, some will be their own employers and some will find a niche in the Linux world.  But most will need to function with Windows.

2011\01\02@180227 by Bob Blick

face
flavicon
face

On Sun, 02 Jan 2011 14:57:37 -0800, "Marcel Duchamp" said:
> On 1/2/2011 2:19 PM, Byron Jeff wrote:

> Windows
> Linux

Perhaps a good time for [OT]?

Thanks,

Bob


-- http://www.fastmail.fm - Faster than the air-speed velocity of an
                         unladen european swallow

2011\01\02@181036 by Michael Watterson
face picon face
On 02/01/2011 20:01, Byron Jeff wrote:
>
> Finally, you have meticulously avoided discussing my point about having to
> manage the ICSP interface to PGD, PGC, and MCLR. With a bootloader, the
> only item the target requires is a high value pulldown resistor on an out
> of the way port pin. PortB on any part becomes completely free for
> development without any additional management.
>
> I'm trying to comprehend why my discussion of bootloaders seems to
> invalidate traditional programmers and causes these circular discussions.
> Especially when functioning in a non Windows environment, programmers are
> not end all and be all of development as the support tools are limited.
>
> It's not just about cost. It's about simplicity and versitility too.
>
> BAJ
>
many SM Pic in 18F family have dedicated ICSP pins
Also I have had no difficulty on 16F877A, 16F628, 18F2550, 18F4550 sharing pins between LCD, keypad and ICSP.

Wouter's bootloader is excellent, But only really useful I buy the chips that way.
Also a Bootloader uses some space. May not be an issue.

I prefer the flexibility to use either and the Pickit2 is a general purpose tool. I still have serial & parallel on my laptop. I still have my JDM style Serial port programmer, but it needs a real serial port and bypass of Windows OS to work. The Pickit2 really worth the money even if you don't program pics with it,

2011\01\02@183617 by Michael Watterson

face picon face
On 02/01/2011 23:02, Bob Blick wrote:
> On Sun, 02 Jan 2011 14:57:37 -0800, "Marcel Duchamp" said:
>> On 1/2/2011 2:19 PM, Byron Jeff wrote:
>> Windows
>> Linux
> Perhaps a good time for [OT]?
>
> Thanks,
>
> Bob
>
>
or bed and good book

2011\01\03@073842 by Olin Lathrop

face picon face
Byron Jeff wrote:
> I find them infinitely less annoying than the management of ICSP
> interface that is required when using a traditional programmer.

I'm not sure what "management" you are referring to.  Like a bootloader, a
programmer has to connect to the target PIC somehow.  ICSP uses two data
lines, clock and data (PGC and PGD), and MCLR.  But that's only during
programming.  These lines all function normally when the PIC is running.

You do have to consider the connection to the rest of the circuit when these
lines are driven during programming, but in my experience that is easily
solved.  On larger PICs it's easy just to leave the lines unused and
dedicate them to ICSP.  Some PICs even have dedicated ICSP lines, so it
becomes completely free because there is nothing else those pins could be
doing.  On smaller PICs where you really need every pin, there is always a
function or two that can tolerate a resistor between the PIC and the
external (to the PIC) function.

I do this for a living and have probably seen over 100 PIC projects.  I can
tell you that dealing with the dual use of the ICSP lines just isn't a
problem in most cases.  About the only time I had to make compromises was
with the 10F PICs.  They only have 3 I/O lines and one input or MCLR line.
3 of these 4 pins participate in ICSP, so you do have to think about it.
However, a bootloader isn't a solution because these little PICs can't write
to their own program memory.  I don't remember having any serious ICSP
conflict issue on any PIC that was big enough that could have supported a
bootloader.

As Dave also said, I agree bootloaders have their place.  I've used them a
bunch of times, usually when the firmware needed to be field upgradable.
Bootloaders just don't make any sense to me for regular development.


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

2011\01\03@094519 by Brian Gregory

flavicon
face
In-Reply-To: <KILLspam20110102172402.GB5850KILLspamspammail.clayton.edu>

Byron,

{Quote hidden}

But how do you do your debugging?

Brian Gregory.
RemoveMEbriangTakeThisOuTspamcix.compulink.co.uk

2011\01\03@100110 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 07:39:39AM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > I find them infinitely less annoying than the management of ICSP
> > interface that is required when using a traditional programmer.
>
> I'm not sure what "management" you are referring to.  Like a bootloader, a
> programmer has to connect to the target PIC somehow.  ICSP uses two data
> lines, clock and data (PGC and PGD), and MCLR.  But that's only during
> programming.  These lines all function normally when the PIC is running.

OK Olin, I'm finally going to plead ignorance. When I used ICSP a while
ago, I never connected anything to PGC and PGD so I could run my
application while the programmer is still connected.
>
> You do have to consider the connection to the rest of the circuit when these
> lines are driven during programming, but in my experience that is easily
> solved.  On larger PICs it's easy just to leave the lines unused and
> dedicate them to ICSP.  Some PICs even have dedicated ICSP lines, so it
> becomes completely free because there is nothing else those pins could be
> doing.  On smaller PICs where you really need every pin, there is always a
> function or two that can tolerate a resistor between the PIC and the
> external (to the PIC) function.

This is precisely the "management" I was referring to. There's no thought
process in my system as the bootloader pin, which generally is the input
associated with MCLR, is dedicated to the task on some out of the way pin
of the chip. Port B is left completely clear with no management necessary.

> I do this for a living and have probably seen over 100 PIC projects.  I can
> tell you that dealing with the dual use of the ICSP lines just isn't a
> problem in most cases.  About the only time I had to make compromises was
> with the 10F PICs.  They only have 3 I/O lines and one input or MCLR line..
> 3 of these 4 pins participate in ICSP, so you do have to think about it.
> However, a bootloader isn't a solution because these little PICs can't write
> to their own program memory.  I don't remember having any serious ICSP
> conflict issue on any PIC that was big enough that could have supported a
> bootloader.

Our experiences differ. From the very beginning of ICSP, which I will admit
was much better than the parallel programming algorithms of the original
16C5X chips, I always had to think about not only those two pins, but more
importantly the PGM pin that was introduced with LVP. Now that is a
dedicated pin that is a useless appendage smack in the middle of a port.

Thank goodness Microchip finally woke up and fixed that disaster with an
unlock key. Now if I can only get that to work.

Honestly, if Microchip had released the hardware debugging protocol so that
3rd party programmers and applications could hardware debug the chip, I may
have taken more time to manage ICSP, as there is an added value for that.
But early on it was some "black magic" that only their programmers could
do. I was not going to run the software associated with those programmers,
so they did not have value to me.

>
> As Dave also said, I agree bootloaders have their place.  I've used them a
> bunch of times, usually when the firmware needed to be field upgradable.
> Bootloaders just don't make any sense to me for regular development.

I understand. I want to reiterate that it makes sense to me for regular
development. I'm not espousing that everyone should switch.

BTW the "code dumper" (my pet name) will serve as a regular ICSP
programmer. It's just than in my particular application, its minimal usage
dictates that low parts count, easily available (or junkbox) parts, and get
the job done simplicity are the goalset.
But in comparison to a $30 PicKit 2, it doesn't have value if it's your
primary development environment.

USB killed the simple programmer market because USB endpoints require
intelligence in order to operate. I cannot think of a device that can run
the USB protocol, and is readily available, other than USB to serial
cables. So that's the target.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@103214 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 09:45:00AM -0500, Brian Gregory wrote:
{Quote hidden}

Good question. I have two primary methods:

1) Simulation. I use the gpsim simulator to do overview testing. It usually
catches the obvious errors and gives a good first crack at working
software.

2) Serial debugging through the bootloader port. There is a serial
interface that's available via the bootloader pin(s). And the bootloaders
serial read/write routines are available for me to use. So I simply print
messages, data, status through that serial port once I get the application
on the chip.

As stated elsewhere I'm not a Windows guy. I haven't used MPLAB since the
DOS days of the mid 1990's. Chips that I used before PICs, like the
Motorola 68K family did not have hardware debugging either. So I never
missed something that I never had.

It makes little sense (for me, for me, for me, and FOR ME!) to flip my
entire setup to run a single application so that I can get hardware
debugging. I know some developers that do (i.e. keep a DOS machine around
to run a single app for example). Doesn't happen to be my style. So I adapt
whatever tools I have available to fit the environment I'm using.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@122222 by Olin Lathrop

face picon face
Byron Jeff wrote:
> OK Olin, I'm finally going to plead ignorance. When I used ICSP a
> while
> ago, I never connected anything to PGC and PGD so I could run my
> application while the programmer is still connected.

I do that routinely too.  My programmers can deliberately be put in a high
impedence state so that they don't conflict with most target circuits.

> I cannot think of a device that can run
> the USB protocol, and is readily available, other than USB to serial
> cables.

You mean other than the LProg ;-)


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

2011\01\03@133241 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 12:23:19PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > OK Olin, I'm finally going to plead ignorance. When I used ICSP a
> > while
> > ago, I never connected anything to PGC and PGD so I could run my
> > application while the programmer is still connected.
>
> I do that routinely too.  My programmers can deliberately be put in a high
> impedence state so that they don't conflict with most target circuits.
>
> > I cannot think of a device that can run
> > the USB protocol, and is readily available, other than USB to serial
> > cables.
>
> You mean other than the LProg ;-)

When LProg can program 16F193X parts (along with the absolutely totally
cool 12F1822. Man I cannot wait for these to get into full production),
then we'll talk.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@143200 by Olin Lathrop

face picon face
Byron Jeff wrote:
>>> I cannot think of a device that can run
>>> the USB protocol, and is readily available, other than USB to serial
>>> cables.
>>
>> You mean other than the LProg ;-)
>
> When LProg can program 16F193X parts (along with the absolutely
> totally cool 12F1822. Man I cannot wait for these to get into full
> production), then we'll talk.

What I meant is that the LProg is a "readily available device that can run
the USB protocol".  It is not much differently priced than USB to serial
converters, but allows direct control over individual data line transitions..


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

2011\01\03@145040 by Olin Lathrop

face picon face
Byron Jeff wrote:
> So from everything that I've gathered so far, there should be no
> problem
> with starting the part with MCLR, PGD, and PGC all at Vil, waiting an
> arbitrary amount of time, then clocking in the key.

I have this working now in a test program.  I hold everything low, including
Vdd, turn on Vdd, clock in the key sequence, and it enters programming mode..

I can also confirm that you do indeed need one more clock pulse after
clocking in the 32 bit key.  I tried just the 32 bit key first, which didn't
work.  Then I clocked in a additional 0 bit and it entered program mode.  I
checked that by reading out the device ID.  That's a good way to verify you
are in program mode without a lot of everything else having to work.  The
device ID doesn't depend on anything programmed into the chip, is a fixed
known value, and always contains a mix of 0s and 1s.  Usually when things
aren't working you get all 0s or all 1s.  The chance of all 14 bits of the
device ID coming out right randomly is pretty much zero.

So far I've got the regular high voltage program mode entry and all the
other read/write/erase stuff working in the production firmware and
software.  I tested the low voltage program mode entry in a special test
program I have just for the purpose of experimenting with the programming
interface.

I'll let you know when I've got LVP working for real in production code.  At
that point I'll button everything up and update the release on the web site..
That will allow you to look and the code and maybe spot something you're
doing differently.


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

2011\01\03@162240 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 02:51:37PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > So from everything that I've gathered so far, there should be no
> > problem
> > with starting the part with MCLR, PGD, and PGC all at Vil, waiting an
> > arbitrary amount of time, then clocking in the key.
>
> I have this working now in a test program.  I hold everything low, including
> Vdd, turn on Vdd, clock in the key sequence, and it enters programming mode.

Excellent!

> I can also confirm that you do indeed need one more clock pulse after
> clocking in the 32 bit key.  I tried just the 32 bit key first, which didn't
> work.  Then I clocked in a additional 0 bit and it entered program mode.
I thought that I tested that. I will try again and triple check the key.

> I
> checked that by reading out the device ID.  That's a good way to verify you
> are in program mode without a lot of everything else having to work.  The
> device ID doesn't depend on anything programmed into the chip, is a fixed
> known value, and always contains a mix of 0s and 1s.  Usually when things
> aren't working you get all 0s or all 1s.  The chance of all 14 bits of the
> device ID coming out right randomly is pretty much zero.

That's always my first test. Goto config memory and read and increment the
first 6 addresses. All zeros or all ones on each of the six addresses
means that it doesn't work.

> So far I've got the regular high voltage program mode entry and all the
> other read/write/erase stuff working in the production firmware and
> software.  I tested the low voltage program mode entry in a special test
> program I have just for the purpose of experimenting with the programming
> interface.

Cool.

>
> I'll let you know when I've got LVP working for real in production code.  At
> that point I'll button everything up and update the release on the web site.
> That will allow you to look and the code and maybe spot something you're
> doing differently.

I think I need to triple check the key. My test harness requires putting in
the individual bits. So with 32 bits, even though I double checked the
string, being one bit off can cause it not to work.

Last thing I need to do is triple check that MCLR cannot be disabled in LVP mode. I believe I saw that in the data sheet.

Thanks for the help Olin.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@165835 by Olin Lathrop

face picon face
Byron Jeff wrote:
> I think I need to triple check the key. My test harness requires
> putting in the individual bits. So with 32 bits, even though I double
> checked the string, being one bit off can cause it not to work.

The key I used was 4D434850h clocked in LSB to MSB order, then one 0 bit
following the key.

> Last thing I need to do is triple check that MCLR cannot be disabled
> in LVP mode. I believe I saw that in the data sheet.

Right.  They have to do that to support the key program entry mode.  If MCLR
wasn't active, then the device could be running with MCLR low.  When
running, it shouldn't be looking for the key.  If you want to use MCLR as a
input pin, you have to disable the key entry mode and use normal Vpp program
mode entry.


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

2011\01\03@165933 by William \Chops\ Westfield

face picon face

>> I cannot think of a device that can run
>> the USB protocol, and is readily available,

Arduino ?

I've always wanted to write a PIC programmer for Arduino...

BillW

2011\01\03@175456 by alan.b.pearce

face picon face
> >> I cannot think of a device that can run
> >> the USB protocol, and is readily available,
>
> Arduino ?

Or any of the PIC24FJxxxGBxxx family, and a reasonable number of smaller PIC24 chips, some (possibly all, haven't checked) of the PIC32 chips, a selection of the PIC33 series, and a dose of the PIC18 ...

> I've always wanted to write a PIC programmer for Arduino...

Oh, you mean like using a Pickit 2 for a non-Microchip family as mentioned earlier in this thread ...
-- Scanned by iCritical.

2011\01\03@181858 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 05:54:43PM -0500, TakeThisOuTalan.b.pearceEraseMEspamspam_OUTstfc.ac.uk wrote:
> > >> I cannot think of a device that can run
> > >> the USB protocol, and is readily available,
> >
> > Arduino ?
>
> Or any of the PIC24FJxxxGBxxx family, and a reasonable number of smaller
> PIC24 chips, some (possibly all, haven't checked) of the PIC32 chips, a
> selection of the PIC33 series, and a dose of the PIC18 ...

Same catch-22 as usual Alan. You have to program each of these before you
can use it as a programmer.

It's really the same with the Arduino, except that it comes preprogrammed.

The most cost effective for a hobbyist if they are going to purchase a part
would be something like a 18F14K50 in a Jaluino format:

http://justanotherlanguage.org/content/jaluino

But it always gets back to my core premise: in order to make one, you have
to have one or something like it.

PCs do not come with software wigglable pins anymore. I saw it for the
first time when I saw an Acer desktop with only USB ports in the mid
1990's. A student of mine had bought it because it was "cute". All I could
think was "Uh Oh!"

It's almost worth keeping around a single MB with a parallel port just for
that task. Something that can boot from a USB stick would be perfect.

>
> > I've always wanted to write a PIC programmer for Arduino...
>
> Oh, you mean like using a Pickit 2 for a non-Microchip family as mentioned earlier in this thread ...

Costly for the job to be done. Make it a challenge:

What is the cheapest over the counter device that can be plugged into a USB
port only PC where pins can be wiggled in software?

Not mail order, over the counter at a typical big box store.

I hope you'll see where I'm coming from...

BAJ


-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@182021 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 04:59:32PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > I think I need to triple check the key. My test harness requires
> > putting in the individual bits. So with 32 bits, even though I double
> > checked the string, being one bit off can cause it not to work.
>
> The key I used was 4D434850h clocked in LSB to MSB order, then one 0 bit
> following the key.

That's 'MCHP' in ASCII. In binary it should be:

000010100001001011000010101100100

I will test it again when I get a chance.

>
> > Last thing I need to do is triple check that MCLR cannot be disabled
> > in LVP mode. I believe I saw that in the data sheet.
>
> Right.  They have to do that to support the key program entry mode.  If MCLR
> wasn't active, then the device could be running with MCLR low.  When
> running, it shouldn't be looking for the key.  If you want to use MCLR as a
> input pin, you have to disable the key entry mode and use normal Vpp program
> mode entry.

I figured as much. So I may end up programming the parts in HVP mode
anyway. But I want to make sure I know how to do LVP too.

Thanks again.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\03@200021 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 06:36:26PM -0500, Byron Jeff wrote:
> On Mon, Jan 03, 2011 at 04:59:32PM -0500, Olin Lathrop wrote:
> > Byron Jeff wrote:
> > > I think I need to triple check the key. My test harness requires
> > > putting in the individual bits. So with 32 bits, even though I double
> > > checked the string, being one bit off can cause it not to work.
> >
> > The key I used was 4D434850h clocked in LSB to MSB order, then one 0 bit
> > following the key.
>
> That's 'MCHP' in ASCII. In binary it should be:
>
> 000010100001001011000010101100100
>
> I will test it again when I get a chance.

Got my chance. Worked like a champ!

Got a word to program by hand. Now to automate it, since my first crack at
it fails.

Thanks Olin!

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\04@001836 by Christopher Head

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

On Mon, 3 Jan 2011 18:32:04 -0500
Byron Jeff <RemoveMEbyronjeffspamTakeThisOuTmail.clayton.edu> wrote:

{Quote hidden}

How about something based on an FTDI chip? I can't say for sure because
I've never investigated myself, but I have heard that as well as
operating as USB-to-serial converters (with their much-maligned
inability to reliably order changes on different pins), they also have
some kind of library or API that one can download that allows
lower-level control over pin states.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: GnuPT 2.7.2

iEYEARECAAYFAk0iragACgkQXUF6hOTGP7du6wCgjur+mzBSCL3nFR/EK7TaHqmX
VNUAoI1xQbTCKfb1jFp8u2R83cYm3nIP
=hawf
-----END PGP SIGNATURE-----

2011\01\04@005154 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 1:18 PM, Christopher Head <headchEraseMEspam.....gmail.com> wrote:
> How about something based on an FTDI chip? I can't say for sure because
> I've never investigated myself, but I have heard that as well as
> operating as USB-to-serial converters (with their much-maligned
> inability to reliably order changes on different pins), they also have
> some kind of library or API that one can download that allows
> lower-level control over pin states.
>

That is actually quite possible. In fact, many simple JTAG debuggers
are based on FT2232x (FT2232D or FT2232H). Many of them
are just FT2232x device plus a level shifter. They support a mode
called MPSSE.
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE.htm

Projects:
libftdi: http://www.intra2net.com/en/developer/libftdi/
OpenOCD: http://sourceforge.net/projects/openocd/
UrJtag: http://urjtag.sourceforge.net/

However, I do not know of any support for PICs using FTDI
based JTAG programmer other than the limit support of
OpenOCD PIC32 support.

On the other hand, if you want to buy a ready-made
FT2232x based debugger, the price is not really that
cheap compared to the US$35 PICKit 2.

Eg: http://www.olimex.com/dev/pricelist.html
Olimex ARM-USB-TINY costs Euro 39.95.

-- Xiaofa

2011\01\04@005646 by Mark Rages

face picon face
On Mon, Jan 3, 2011 at 11:51 PM, Xiaofan Chen <EraseMExiaofancspamgmail.com> wrote:
> However, I do not know of any support for PICs using FTDI
> based JTAG programmer other than the limit support of
> OpenOCD PIC32 support.
>
> On the other hand, if you want to buy a ready-made
> FT2232x based debugger, the price is not really that
> cheap compared to the US$35 PICKit 2.
>

The FTDI cable I mentioned is $18.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
RemoveMEmarkragesEraseMEspamEraseMEmidwesttelecine.co

2011\01\04@022034 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 1:56 PM, Mark Rages <RemoveMEmarkragesspam_OUTspamKILLspamgmail.com> wrote:
> On Mon, Jan 3, 2011 at 11:51 PM, Xiaofan Chen <RemoveMExiaofancTakeThisOuTspamspamgmail.com> wrote:
>> However, I do not know of any support for PICs using FTDI
>> based JTAG programmer other than the limit support of
>> OpenOCD PIC32 support.
>>
>> On the other hand, if you want to buy a ready-made
>> FT2232x based debugger, the price is not really that
>> cheap compared to the US$35 PICKit 2.
>>
>
> The FTDI cable I mentioned is $18.
>

One huge difference is that the FT2232x based ones can
have two channel and the MPSSE mode is much better
to deal with than the bit bang mode of FT232x. There are
indeed serial based JTAG debuggers using FT232x but it
is much slower and not popular at all.

There were discussions in the OpenOCD about this
and the consensus is that it is mostly not worth
the efforts to use FT232x instead of FT2232x.


-- Xiaofa

2011\01\04@023141 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 3:20 PM, Xiaofan Chen <EraseMExiaofancspamspamspamBeGonegmail.com> wrote:
{Quote hidden}

forum.sparkfun.com/viewtopic.php?f=18&t=21411
The author of the bitbabg-jtag says that FT2232D based
Olimex ARM-USB-Tiny is 90 times faster than his
FT232R based serial JTAG debugger.

-- Xiaofa

2011\01\04@030234 by Mark Rages

face picon face
On Tue, Jan 4, 2011 at 1:31 AM, Xiaofan Chen <spamBeGonexiaofancSTOPspamspamEraseMEgmail.com> wrote:
{Quote hidden}

I've got the FT232 cable on my desk and am testing it now.

I made a Python script to set bitbang mode with libftdi and write a
repeating 0x00,0xff pattern to it.  If I set the baudrate to 1382400 I
get 677 kbyte / s transfer to the chip.  A scope confirms the data
coming out as 1.38/2 MHz squarewave, with occasional gaps in it.

So the 2232D chip can do 90 times faster than that?  That would be 60
MB/sec, which is the theoretical maximum for USB 2.0 Hi-Speed mode.
I must admit I'm a bit skeptical, but I don't have a 2232D on hand to
experiment with.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
spamBeGonemarkragesspamKILLspammidwesttelecine.co

2011\01\04@035935 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 4:02 PM, Mark Rages <.....markragesspam_OUTspamgmail.com> wrote:
> I've got the FT232 cable on my desk and am testing it now.
>
> I made a Python script to set bitbang mode with libftdi and write a
> repeating 0x00,0xff pattern to it.  If I set the baudrate to 1382400 I
> get 677 kbyte / s transfer to the chip.  A scope confirms the data
> coming out as 1.38/2 MHz squarewave, with occasional gaps in it.
>
> So the 2232D chip can do 90 times faster than that?  That would be 60
> MB/sec, which is the theoretical maximum for USB 2.0 Hi-Speed mode.
> I must admit I'm a bit skeptical, but I don't have a 2232D on hand to
> experiment with.
>

No, FT2232D is full speed USB device. FT2232H is high speed USB
device. both will not achieve 60MB/sec. None of the high speed USB
device can do 60MB/sec (usually less than 40MB/sec and FT2232H
is much less than that).

The reason that FT2232D is much faster than FT232R is because
of the MPSSE Engine which is much easier to deal with than
bit-bang of FT232R.
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE.htm


-- Xiaofan

2011\01\04@054027 by alan.b.pearce

face picon face
> > Or any of the PIC24FJxxxGBxxx family, and a reasonable number of smaller
> > PIC24 chips, some (possibly all, haven't checked) of the PIC32 chips, a
> > selection of the PIC33 series, and a dose of the PIC18 ...
>
> Same catch-22 as usual Alan. You have to program each of these before you
> can use it as a programmer.
>
> It's really the same with the Arduino, except that it comes preprogrammed..

So where is the problem? Get Microchip to pre-program a reel or bunch of tubes or whatever you require with whatever your preferred bootloader is!!!

I really think you are making a mountain out of a molehill over all this, insisting on starting with a blank chip.
-- Scanned by iCritical.

2011\01\04@054629 by alan.b.pearce

face picon face
> > On the other hand, if you want to buy a ready-made
> > FT2232x based debugger, the price is not really that
> > cheap compared to the US$35 PICKit 2.
> >
>
> The FTDI cable I mentioned is $18.

So close enough to Olins programmer that the difference isn't worth quibbling over ...
-- Scanned by iCritical.

2011\01\04@063941 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 6:46 PM,  <TakeThisOuTalan.b.pearce.....spamTakeThisOuTstfc.ac.uk> wrote:
>> > On the other hand, if you want to buy a ready-made
>> > FT2232x based debugger, the price is not really that
>> > cheap compared to the US$35 PICKit 2.
>> >
>>
>> The FTDI cable I mentioned is $18.
>
> So close enough to Olins programmer that the difference isn't
> worth quibbling over ...
> --

The FTDI based debugger can do a lot actually, it supports
many ARM based MCU/MPU or even other things like
CPLD and others.

Check out OpenOCD and UrJtag.
http://www.urjtag.org
http://openocd.sourceforge.net/

So if you can teach them to program
PICs, they become even more useful.

There are other multi-platform generic programmer/debuggers like
Versaloon (open source). It does not support PICs, but
it does support AVR/AVR32/MSP430/ARM/etc. It is not
based on FTDI though.
http://www.versaloon.com/index.html


-- Xiaofa

2011\01\04@072231 by Olin Lathrop

face picon face
Byron Jeff wrote:
>> The key I used was 4D434850h clocked in LSB to MSB order, then one 0
>> bit following the key.
>
> That's 'MCHP' in ASCII. In binary it should be:
>
> 000010100001001011000010101100100

I don't see how you got your string above from 4D434850h.  I got that
straight out of the programming spec.  They actually show it in binary, I
converted it to HEX to make it easier to write.  I have the HEX value in my
source code, so I know it's right.

Ah, I just noticed you have the right bits but flipped MSB to LSB.  The key
sequence in the programming spec must be sent in LSB to MSB order.  Your
sequence would be correct if it were clocked MSB to LSB order.  However,
things are generally clocked in least to most significant bit order with
Microchip ICSP, so writing it as you did above is misleading and is just
asking for human error.

Write a routine that clocks out words starting with the LSB, then your
source code will be more understandable in reference to the programming
spec, which will reduce the chance of error.


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

2011\01\04@074500 by Byron Jeff

flavicon
face
OK. On to round two.

I'm making progress in getting programming done. I also incorporated the
LVP key into my script. It works consistently. I'm testing with a 16F1939.

The only failure is bulk erase. According to the progspec it's command 0x09
then wait a bit and the entire chip should be erased. The only problem is
that it doesn't work. It doesn't erase the chip, and once it's done, the
chip no longer seems to be in programming mode, and requires the LVP key to
be resent. And still the chip isn't erased.

Row erase does work properly, but will cause a much longer delay than
erasing the entire chip at one time.

Any ideas?

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\04@075724 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 9:01 PM, Byron Jeff <TakeThisOuTbyronjeffKILLspamspamspammail.clayton.edu> wrote:
> OK. On to round two.
>
> I'm making progress in getting programming done. I also incorporated the
> LVP key into my script. It works consistently. I'm testing with a 16F1939..
>
> The only failure is bulk erase. According to the progspec it's command 0x09
> then wait a bit and the entire chip should be erased. The only problem is
> that it doesn't work. It doesn't erase the chip, and once it's done, the
> chip no longer seems to be in programming mode, and requires the LVP key to
> be resent. And still the chip isn't erased.
>
> Row erase does work properly, but will cause a much longer delay than
> erasing the entire chip at one time.
>
> Any ideas?

Not so sure if this helps or not. PICkit 2 supports PIC16F1639
and its source code is available. The programming sepc
is somewhat buried in the data file though.
http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit2_PCAppSource_V2_61.zip

Parser for the data file (Linux/Windows/etc)
http://home.pacbell.net/theposts/picmicro/dat2text-1.00.tar.gz

GUI Editor for the data file (DotNet based)
http://www.microchip.com/forums/tm.aspx?m=473925





-- Xiaofa

2011\01\04@080325 by Byron Jeff

flavicon
face
On Tue, Jan 04, 2011 at 05:40:13AM -0500, .....alan.b.pearcespamRemoveMEstfc.ac.uk wrote:
> > > Or any of the PIC24FJxxxGBxxx family, and a reasonable number of smaller
> > > PIC24 chips, some (possibly all, haven't checked) of the PIC32 chips, a
> > > selection of the PIC33 series, and a dose of the PIC18 ...
> >
> > Same catch-22 as usual Alan. You have to program each of these before you
> > can use it as a programmer.
> >
> > It's really the same with the Arduino, except that it comes preprogrammed.
>
> So where is the problem? Get Microchip to pre-program a reel or bunch of tubes or whatever you require with whatever your preferred bootloader is!!!

$29 setup fee and a minimum $60 order? Just checked on microchipdirect.com.

>
> I really think you are making a mountain out of a molehill over all this, insisting on starting with a blank chip.

Chips come blank. Unless you are planning on selling them, using Mchip's
pre-programming service isn't cost effective. Better off buying a PicKit 2
for $34 in that case.

Right now with a USB to serial cable and well less than $5 of over the
counter parts, I have a working programmer on a breadboard. Exactly what my
goal was when I started.

BAJ
-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\04@082452 by Byron Jeff

flavicon
face
On Mon, Jan 03, 2011 at 02:32:57PM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> >>> I cannot think of a device that can run
> >>> the USB protocol, and is readily available, other than USB to serial
> >>> cables.
> >>
> >> You mean other than the LProg ;-)
> >
> > When LProg can program 16F193X parts (along with the absolutely
> > totally cool 12F1822. Man I cannot wait for these to get into full
> > production), then we'll talk.
>
> What I meant is that the LProg is a "readily available device that can run
> the USB protocol".  It is not much differently priced than USB to serial
> converters, but allows direct control over individual data line transitions.

I took a read of the Lprog page. I see three potential issues:

1) 3.3V max output means that it cannot program 5V chips without additional
level shifters on the target. Little more than a transistors and a base
resistor, but it's still required.

2) Unsure how the part shows up in terms of drivers. Does it come across as
a standard USB serial port?

3) A minor deal: only available from EmbedInc and not over the counter.

Finally the modem control signals of a USB serial converter do facilitate
control over individual data line transistions. That's exactly how I've
gotten my programmer to work so far.

So it's not an exact apples to apples comparison.

BAJ

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

2011\01\04@082624 by Olin Lathrop

face picon face
part 1 1003 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

Byron Jeff wrote:
> The only failure is bulk erase. According to the progspec it's
> command 0x09 then wait a bit and the entire chip should be erased.

Not exactly, at least not with a 16F1827, which is what I am testing with.

> The only problem is that it doesn't work. It doesn't erase the chip,
> and once it's done, the chip no longer seems to be in programming
> mode, and requires the LVP key to be resent. And still the chip isn't
> erased.

Byron, I can't help but think your kludgy setup is causing problems.  You
seem to be willing to spare no expense to save a nickle.  You are creating
one heck of a costly free programmer after your time is considered.

But anyway, I have attached the my erase routine for the 16F182x subfamily.
This has been tested and works as far as I can tell.  I do the erase
procedures all from the host, since it's a one time operation and therefore
whether it takes a extra 100ms doesn't matter.


part 2 1451 bytes content-type:text/plain; name="x.txt"
(decoded base64)

{
*******************************************************************************
*
*   Subroutine PICPRG_ERASE_16F182X (PR, STAT)
*
*   Erase all erasable non-volatile memory in the target chip except the
*   calibration words.
}
procedure picprg_erase_16f182x(        {erase routine for 16F182x}
 in out  pr: picprg_t;                {state for this use of the library}
 out     stat: sys_err_t);            {completion status}
 val_param;

begin
 picprg_reset (pr, stat);             {reset target to put it into known state}
 if sys_error(stat) then return;

 picprg_cmdw_writing (pr, stat);      {indicate the target is being written to}
 if sys_error(stat) then return;

 picprg_send6 (pr, 2#000000, stat);   {LOAD CONFIGURATION, set adr to config region}
 if sys_error(stat) then return;
 picprg_send14ss (pr, 0, stat);       {send dummy data word}
 if sys_error(stat) then return;

 picprg_send6 (pr, 2#01001, stat);    {BULK ERASE PROGRAM MEMORY (9)}
 if sys_error(stat) then return;
 picprg_cmdw_wait (pr, 0.010, stat);
 if sys_error(stat) then return;

 picprg_send6 (pr, 2#01011, stat);    {BULK ERASE DATA MEMORY (11)}
 if sys_error(stat) then return;
 picprg_cmdw_wait (pr, 0.010, stat);
 if sys_error(stat) then return;

 picprg_reset (pr, stat);             {reset target to guaranteed known state}
 if sys_error(stat) then return;
 end;

part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\01\04@082701 by Byron Jeff

flavicon
face
On Tue, Jan 04, 2011 at 07:23:29AM -0500, Olin Lathrop wrote:
{Quote hidden}

I ran into exactly that human error, as I do have a routine that reverses
the bits and writes them out LSB first. So when I put the string above in,
it did not work. I had to reverse it.
So your point was right on target.

BAJ

-- Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjef

2011\01\04@082932 by Byron Jeff

flavicon
face
On Tue, Jan 04, 2011 at 07:57:21AM -0500, Xiaofan Chen wrote:
{Quote hidden}

This item was exactly what I needed. I was just perusing that data file and
its format this morning.

BAJ

>
> GUI Editor for the data file (DotNet based)
> www.microchip.com/forums/tm.aspx?m=473925
>
>
>
>
>
> --
> Xiaofan
> -

2011\01\04@090329 by Olin Lathrop

face picon face
Byron Jeff wrote:
> 2) Unsure how the part shows up in terms of drivers. Does it come
> across as a standard USB serial port?

No, it comes with it's own Windows driver.  We decided not to make it look
like a serial port because the application can't rely on the port number.
The driver handles multiple devices connected to the same machine, and the
application can enumerate all of them and get their name strings, even if
they are in use by other applications.  This was something I felt was
important for "just works" operation.


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

2011\01\04@091218 by Byron Jeff

flavicon
face
On Tue, Jan 04, 2011 at 08:27:21AM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > The only failure is bulk erase. According to the progspec it's
> > command 0x09 then wait a bit and the entire chip should be erased.
>
> Not exactly, at least not with a 16F1827, which is what I am testing with..

With Xiaofan's help I have the exact script for the PicKit 2:

Script number: 4
Script name: MR_ChpEraseEE10msI
Script version: 0
Script length: 17
Script code: aaee bb06 bb00 aaf2 bb00 aaf2 bb00 aaee bb06 bb09 aae8 bb02 aaee bb06 bb0b aae8 bb02
Script comment: Erase progmem (09) & EE(0B), int timed 10ms

aa are command bytes, bb are data bytes.

aaee bb06 bb00: shift out 6 bits of second data byte 0, i.e. send command 0: Load Config
aaf2 bb00: Shift byte. Sends the 16 data bits for the Load Config.
aaee bb06 aa09: shift out 6 bits of second data byte 9, i.e. send command 9: Bulk Erase
aae8 bb02: Delay 5.42 ms for two cycles (i.e. 11 ms)
aaee bb06 aa0b: shift out 6 bits of second data byte b, i.e. send command b: Bulk Erase Data
aae8 bb02: Delay 5.42 ms for two cycles (i.e. 11 ms)

>
> > The only problem is that it doesn't work. It doesn't erase the chip,
> > and once it's done, the chip no longer seems to be in programming
> > mode, and requires the LVP key to be resent. And still the chip isn't
> > erased.
>
> Byron, I can't help but think your kludgy setup is causing problems.  You
> seem to be willing to spare no expense to save a nickle.  You are creating
> one heck of a costly free programmer after your time is considered.

I'm on vacation. My time is absolutely worthless. I will try to run the
script exactly as described above and see if I get any joy.

>
> But anyway, I have attached the my erase routine for the 16F182x subfamily.
> This has been tested and works as far as I can tell.  I do the erase
> procedures all from the host, since it's a one time operation and therefore
> whether it takes a extra 100ms doesn't matter.

Content-Description: x.txt
{Quote hidden}

Seems to be the same as Microchip's. That good validation. Will test.

BAJ

Content-Description: ATT00001..txt
> -

2011\01\04@091821 by Byron Jeff

flavicon
face
Followup. Both the 16F193X and the 16F182X chips use the same erase
algorithm.

BAJ

On Tue, Jan 04, 2011 at 09:28:29AM -0500, Byron Jeff wrote:
{Quote hidden}

> > --

2011\01\04@131335 by Olin Lathrop

face picon face
Byron Jeff wrote:
> I'm on vacation. My time is absolutely worthless.

It's worth whatever you value it at to do other things then.

In any case, I've finised adding support for the 16F182x subfamily to the
USBProg, USBProg2, and LProg.  The USBProgs use the high voltage program
mode entry method, which includes raising MCLR to over 8 volts.  The LProg
uses the low voltage program entry method, which includes clocking in the
magic 32 bit key.  Everything seems to work correctly.

If you want to look thru the source code, both firmware and host software,
download and install the Development Software release from
http://www.embedinc.com/picprg/sw.htm.


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

2011\01\04@173551 by Byron Jeff

flavicon
face

On Tue, Jan 04, 2011 at 08:27:21AM -0500, Olin Lathrop wrote:
> Byron Jeff wrote:
> > The only failure is bulk erase. According to the progspec it's
> > command 0x09 then wait a bit and the entire chip should be erased.
>
> Not exactly, at least not with a 16F1827, which is what I am testing with.
>
> > The only problem is that it doesn't work. It doesn't erase the chip,
> > and once it's done, the chip no longer seems to be in programming
> > mode, and requires the LVP key to be resent. And still the chip isn't
> > erased.
>
> Byron, I can't help but think your kludgy setup is causing problems.

I must beg to differ my friend. From the errata for the part:

--------------------------------------------------------------
4. Module: In-Circuit Serial Programmingâ„¢ (ICSPâ„¢)

4.1 Bulk Erase Feature not available with Low-Voltage Programming mode

A bulk erase of the program Flash memory or data memory cannot be executed
in Low-Voltage Programming mode.

Work around

Method 1: If ICSP Low-Voltage Programming mode is required, use row
erases to erase the program memory, as described in the Program/Verify
mode section of the Programming Specification. Data memory must be
over-written with the desired values.

Method 2: Use ICSP High-Voltage Programming mode if a bulk erase is
required.
--------------------------------------------------------------

Worked exactly as specified. And when I hooked up the high voltage to the
programmer again, it did bulk erase.

I feel vindicated.

So that means that everything works! Excellent. On to the bootloader.

Should have looked at the errata from the start.

BAJ
--
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff

2011\01\04@180811 by Olin Lathrop

face picon face
Byron Jeff wrote:
> A bulk erase of the program Flash memory or data memory cannot be
> executed in Low-Voltage Programming mode.

That sucks.

I didn't run into this because it apparently doesn't apply to the 16F182x,
at least not to the 16F1827 I have been testing with.  And yes, I tried it
again deliberately just now to make sure I didn't miss something earlier.
Bulk erase works via LVP on that part.


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

2011\01\04@211813 by Xiaofan Chen

face picon face
On Wed, Jan 5, 2011 at 7:09 AM, Olin Lathrop <spamBeGoneolin_piclist@spam@spamspam_OUTembedinc.com> wrote:
> Byron Jeff wrote:
>> A bulk erase of the program Flash memory or data memory cannot be
>> executed in Low-Voltage Programming mode.
>
> That sucks.
>
> I didn't run into this because it apparently doesn't apply to the 16F182x,
> at least not to the 16F1827 I have been testing with.  And yes, I tried it
> again deliberately just now to make sure I didn't miss something earlier.
> Bulk erase works via LVP on that part.
>

You are right for the 16F182x.
http://ww1.microchip.com/downloads/en/DeviceDoc/41390C.pdf

The only culprit is that Vdd should be higher than 2.7V (Pg32).
Row erase works until 2.1V Vdd. The chip itself works down to
1.8V Vdd.

What BAJ mentioned about PIC16F1939 is correct due to
the silicon errata in ICSP module. It does not seem to affect
16F182x.
http://ww1.microchip.com/downloads/en/DeviceDoc/80501C.pdf

-- Xiaofan

2011\01\04@222420 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 9:45 PM, Byron Jeff <TakeThisOuTbyronjeffspamspammail.clayton.edu> wrote:

>> Not so sure if this helps or not. PICkit 2 supports PIC16F1639
>> and its source code is available. The programming sepc
>> is somewhat buried in the data file though.
>> ww1.microchip.com/downloads/en/DeviceDoc/PICkit2_PCAppSource_V2_61.zip
>>
>> Parser for the data file (Linux/Windows/etc)
>> http://home.pacbell.net/theposts/picmicro/dat2text-1.00.tar.gz
>
> This item was exactly what I needed. I was just perusing that data file and
> its format this morning.

BTW, be sure to download the latest device data file. It adds support
for many chips.
ww1.microchip.com/downloads/en/DeviceDoc/PK2DFUpdate-1-62-03.zip
http://www.microchip.com/forums/tm.aspx?m=487219

The updated test version of pk2cmd may be of interests as well.
http://www.microchip.com/forums/tm.aspx?m=540021

>> GUI Editor for the data file (DotNet based)
>> http://www.microchip.com/forums/tm.aspx?m=473925

-- Xiaofa

2011\01\04@223246 by Xiaofan Chen

face picon face
On Wed, Jan 5, 2011 at 11:24 AM, Xiaofan Chen <xiaofancEraseMEspamgmail.com> wrote:
> On Tue, Jan 4, 2011 at 9:45 PM, Byron Jeff <RemoveMEbyronjeffEraseMEspamspam_OUTmail.clayton.edu> wrote:
>
>>> Not so sure if this helps or not. PICkit 2 supports PIC16F1639
>>> and its source code is available. The programming sepc
>>> is somewhat buried in the data file though.
>>> ww1.microchip.com/downloads/en/DeviceDoc/PICkit2_PCAppSource_V2_61.zip
>>>
>>> Parser for the data file (Linux/Windows/etc)
>>> home.pacbell.net/theposts/picmicro/dat2text-1.00.tar.gz
>>
>> This item was exactly what I needed. I was just perusing that data file and
>> its format this morning.
>
> BTW, be sure to download the latest device data file. It adds support
> for many chips.
> ww1.microchip.com/downloads/en/DeviceDoc/PK2DFUpdate-1-62-03.zip
> http://www.microchip.com/forums/tm.aspx?m=487219

The list is not that complete in the forum thread. For example,
the update device file (ver 1.62.3) supports 16F1823/24/26/27/28 family.

> The updated test version of pk2cmd may be of interests as well.
> http://www.microchip.com/forums/tm.aspx?m=540021
>
>>> GUI Editor for the data file (DotNet based)
>>> http://www.microchip.com/forums/tm.aspx?m=473925
>




-- Xiaofa

2011\01\05@021752 by Xiaofan Chen

face picon face
On Tue, Jan 4, 2011 at 10:04 PM, Olin Lathrop <@spam@olin_piclistRemoveMEspamEraseMEembedinc.com> wrote:
> Byron Jeff wrote:
>> 2) Unsure how the part shows up in terms of drivers. Does it come
>> across as a standard USB serial port?
>
> No, it comes with it's own Windows driver.  We decided not to make it look
> like a serial port because the application can't rely on the port number.
> The driver handles multiple devices connected to the same machine, and the
> application can enumerate all of them and get their name strings, even if
> they are in use by other applications.  This was something I felt was
> important for "just works" operation.
>

It is of course good to have control over the driver itself. However, in
the "just works" department, your driver is seriously flawed since
it only works for 32bit Windows. You have not provide 64bit drivers
for them. For 64bit drivers to be used with 64bit Windows Vista
and Windows 7, you also need to pay for the digital signature.

Microchip is using custom drivers with MPLAB IDE but seems
to move to WinUSB based drives under MPLAB X.

You might want to consider move to either Microsoft's
WinUSB (but it does not support Windows 2k) or the
open source libusb-win32.

We paid for the digital signature (from GlobalSign) to get
libusb-win32 device driver to work under 64bit Windows
Vista and Windows 7. It supports Window 2k as well.
http://sourceforge.net/projects/libusb-win32/

Disclaim: I am one of the admins of libusb-win32 project.

-- Xiaofan

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