Searching \ for '[PIC] [gnupic] noob's 1st ques' 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/devices.htm?key=pic
Search entire site for: '[gnupic] noob's 1st ques'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] [gnupic] noob's 1st ques'
2006\01\27@173326 by James Newton, Host

face picon face

> The real question in today's environment is what to do in the
> face of the ever disappearing parallel port? My current
> laptop doesn't have one. Serial ports are marginal from a
> voltage standpoint and USB to Serial converters makes no
> guarantees about modem control signals. It's fast getting to
> the point where one needs a programmable part simply to
> wiggle some pins.

There is a nice long page of programmers available at
http://www.piclist.com/techref/microchip/devprogs.htm that might help our
O.P. find a programmer that works for him/her.

But you raise an interesting question in my mind, regarding the fading away
of the parallel port, poor quality serial ports and, most important, the
need for software to "wiggle pins" on the port. Keep in mind, this is in the
context of "bootstrapping" or starting with PIC's for the beginner who likes
to do things for his/her self.

A long time ago, Tony Nixon designed a programmer that would work on even a
low quality serial port (and it has been tested by other people with USB to
serial adapters) without ANY software! And it is very simple:

<www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html>
You just jumper the handshaking signals on the serial port so that the data
flys out the end at 1200n7 and supply the programming voltage yourself.

I really like that the minimum commands required to tell the PIC to load
this data are documented on that page. This removes the "magic" of the PIC
device programmer and allows the true hacker (in the true sense of that
word) to see exactly what is happening.

The trick is that although no software is actually needed, translating the
hex file into the data stream that needs to be sent out the serial port is
something that a program should be used to do, and the only program that has
ever been written to do it is closed source (source lost) and for the
windows environment.

I'm really curious about two things:

A) is there another programmer that is basically the same as this one?
Serial port, a few basic components and no PIC, just taking a datastream and
not a program...

B) does anyone see any value in writing some open source software to
translate hex files into the datastream needed for the programmer?

If someone writes the program, I will try to host it at piclist.com so it
would be a truly host independent programming solution... Just past your hex
file into a form on the web page, push the button, download the result and
copy it out your serial port.

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


2006\01\28@034030 by Wouter van Ooijen

face picon face
> I'm really curious about two things:
>
> A) is there another programmer that is basically the same as this one?
> Serial port, a few basic components and no PIC, just taking a
datastream and
> not a program...
>
> B) does anyone see any value in writing some open source software to
> translate hex files into the datastream needed for the programmer?

With the flood of new PICs that need new variations of programming
algorithms the 3d question is: who will maintain that software?

And I don't think that circuit is realy very easy. it is one chip, with
at least one timing capacitor, and you must supply separate Vcc and Vdd
(and switch one or both at the appropriate moments).

Wouter van Ooijen

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


2006\01\28@200703 by Byron A Jeff

face picon face
On Sat, Jan 28, 2006 at 09:42:27AM +0100, Wouter van Ooijen wrote:
> > I'm really curious about two things:
> >
> > A) is there another programmer that is basically the same as this one?
> > Serial port, a few basic components and no PIC, just taking a
> datastream and
> > not a program...
> >
> > B) does anyone see any value in writing some open source software to
> > translate hex files into the datastream needed for the programmer?
>
> With the flood of new PICs that need new variations of programming
> algorithms the 3d question is: who will maintain that software?

Agreed. That's why I think an actual programmer application (such as
pikdev) would be more appropriate. pikdev has programmer classes that
implement a programmer hardware abstraction layer. Once implemented, that
class can be used to program any part that pikdev implements.

> And I don't think that circuit is realy very easy. it is one chip, with
> at least one timing capacitor, and you must supply separate Vcc and Vdd
> (and switch one or both at the appropriate moments).

I think there's one paradigm issue here. It's not effective if you put
it in the realm of traditional programmers. I think of this type (and
all of my Trivial programmers too) as firmware dumping circuits. Their place
is not to serve as a traditional programmer, but as a non intelligent tool
to get to intelligent programmers, both self hosting (via bootloaders) and
off chip hosted.

In that context a power flip or two one time per chip isn't too terribly
costly.

BAJ

2006\01\29@034901 by Wouter van Ooijen

face picon face
> I think there's one paradigm issue here. It's not effective if you put
> it in the realm of traditional programmers. I think of this type (and
> all of my Trivial programmers too) as firmware dumping
> circuits. Their place
> is not to serve as a traditional programmer, but as a non
> intelligent tool
> to get to intelligent programmers, both self hosting (via
> bootloaders) and
> off chip hosted.
>
> In that context a power flip or two one time per chip isn't
> too terribly costly.

I was not thinking of cost, but of error-pronesness. That's why I don't
like the timing capacitor(s). And thye switches must be switched at the
right moment, and the Vpp must be 13 Volt, which is *not* the same as a
wall-wart set to 13Volt (if that existed), so I think this progger is
more complex to use (even to use once) than it seems.

To ride your hobby horse: I think programming a bootloader or the
firmware of an intelligent progger is one of the places where LVP is
appropriate.

Wouter van Ooijen

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


2006\01\29@110232 by Byron A Jeff

face picon face
On Sun, Jan 29, 2006 at 09:46:56AM +0100, Wouter van Ooijen wrote:
> > I think there's one paradigm issue here. It's not effective if you put
> > it in the realm of traditional programmers. I think of this type (and
> > all of my Trivial programmers too) as firmware dumping
> > circuits. Their place
> > is not to serve as a traditional programmer, but as a non
> > intelligent tool
> > to get to intelligent programmers, both self hosting (via
> > bootloaders) and
> > off chip hosted.
> >
> > In that context a power flip or two one time per chip isn't
> > too terribly costly.
>
> I was not thinking of cost,

Neither was I. I meant cost in terms of time and difficulty.

> but of error-pronesness.

So we're in the same area.

> That's why I don't like the timing capacitor(s).

I tested my Trivial BootStrapper with a simple feedback loop. The
resistor/cap combo for the 555 is going to get you into a general timing
ballpark. You only have to get it timed somewhere near the center of a serial
character cell. The feedback loop simply loops back the inverted output of
the 555. If the timing is correct you get back a character in the 0x1f, 0x0f,
or 0x07 range.

> And thye switches must be switched at the
> right moment, and the Vpp must be 13 Volt, which is *not* the same as a
> wall-wart set to 13Volt (if that existed), so I think this progger is
> more complex to use (even to use once) than it seems.

I never perceived getting 13V as too difficult a problem. A 7812 regulator
with a diode on the ground leg gets you 12.6V which is good enough for
programming work and cost (in terms of diffculty) only a single 3 pin
regulator, a diode, and a couple of smoothing caps.

Also many PIC parts only require a Vpp of 3.5 above Vdd. So switching 12V
which is readily available on a PC is also doable.

Finally one could build a programmer with automatic Vpp switching. Generally
USB to serial converters do have working modem control signals. However, they
are generally not synchronized to the TX stream. So you cannot have the
precise timing control that programmers like JDM require. But if the modem
control signal is switchable at all, you can use it to switch Vpp. By using
a transistor switch, there would not be any RS-232 voltage level issues as
transistors can switch on with as little as 1V. So a circuit along the lines
of your El Cheap RS-232 interface for WLoader (IIRC a current limiting resistor,
a zener diode clamp, and a switching transistor) would be sufficient to control
Vpp.

> To ride your hobby horse: I think programming a bootloader or the
> firmware of an intelligent progger is one of the places where LVP is
> appropriate.

Yes and no. Yes because it's simpler to wire and test. No because you lose
the PGM permanently, which is untenable primarily because MChip in their infinite
wisdom stuck LVP in the middle of a perfect good 8 bit I/O port. I find
that a strategy of building the LVP version first, testing it, then adding the
Vpp circuit after LVP testing is a workable solution.

My development of the TBS555 bogged down with the RX feedback. It tested
perfectly as an outgoing "Black Hole" a la ZPL. In fact ZPL's python code
could be easily adapted to driving the TBS555.

I'm still debating how important verification is for the bootloader dumper.
Should it be as simple as testing with a blinky LED and then dump a self
verifying bootloader to the part?

BTW James, if you are still reading, having a conversion application to drive
the serial port isn't critical. As I stated above this type of device is not
designed to be a traditional programmer. It's much more akin to P-code/bytecode
interpreters of the past. Get the interpreter onto a new target, then use it
to port all of the rest of the software. Same here as the TBS555 is used solely
to dump in a bootloader, then the bootloader is used from then on to program
the chip.

BAJ

2006\01\29@230328 by James Newton, Host

face picon face
> To ride your hobby horse: I think programming a bootloader or
> the firmware of an intelligent progger is one of the places
> where LVP is appropriate.
>
> Wouter van Ooijen

Ok then, how about an LVP programmer that uses only non-programmed
components and takes a stream from a serial port like Tony's ASCII
programmer. Perhaps the clock signal could be developed without RC circuits.

Again, the point is to not require any programming software, but rather use
a data file that loads a bootloader or like that. The data file only needs
to be developed once, but having server based software for turning a hex
file into such a datafile would be very cool as well.

It really seems to me that it would be nice to have a very simple
programming circuit that could load at least one or two types of blank PIC
chip. And it isn't like these chips stop being made. You can still buy
16F84's and you can still use a 16F84 to make a programmer that will program
just about anything else. Right?

<http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html>

---
James.


2006\01\29@231700 by Xiaofan Chen

face picon face
On 1/30/06, James Newton, Host <.....jamesnewtonKILLspamspam@spam@piclist.com> wrote:

> It really seems to me that it would be nice to have a very simple
> programming circuit that could load at least one or two types of blank PIC
> chip.

If you want simple programmers, what is wrong with those
JDM/tait coupled with pikdev (Linux) or WinPIC/IC-Prog/WinPIC800/PICPGM/...?
Why need another one?

Regards,
Xiaofan

2006\01\29@234243 by Xiaofan Chen

face picon face
On 1/29/06, Wouter van Ooijen <wouterspamKILLspamvoti.nl> wrote:

> To ride your hobby horse: I think programming a bootloader or the
> firmware of an intelligent progger is one of the places where LVP is
> appropriate.

picpgm seems to support many PICs using LVP and with very
simple programmer.
http://www.members.aon.at/electronics/pic/picpgm/index.html

Regards,
Xiaofan

2006\01\30@002718 by Byron A Jeff

face picon face
On Sun, Jan 29, 2006 at 08:03:21PM -0800, James Newton, Host wrote:
> > To ride your hobby horse: I think programming a bootloader or
> > the firmware of an intelligent progger is one of the places
> > where LVP is appropriate.
> >
> > Wouter van Ooijen
>
> Ok then, how about an LVP programmer that uses only non-programmed
> components and takes a stream from a serial port like Tony's ASCII
> programmer. Perhaps the clock signal could be developed without RC circuits.

The clock isn't too very critical. It's just a one shot triggered by the
edge of the start bit. A 555 with a cap and a pot can be easily tuned to
give the proper timing with just a small bit of trimming.
`
> Again, the point is to not require any programming software, but rather use
> a data file that loads a bootloader or like that. The data file only needs
> to be developed once, but having server based software for turning a hex
> file into such a datafile would be very cool as well.

After hearing Wouter's arguments I'm more inclined to agree with him. There
is already a vast amount of programming software that would only need be
fitted with a driver.

> It really seems to me that it would be nice to have a very simple
> programming circuit that could load at least one or two types of blank PIC
> chip. And it isn't like these chips stop being made. You can still buy
> 16F84's and you can still use a 16F84 to make a programmer that will program
> just about anything else. Right?
>
> <http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html>

True. But if it can program a 16F84, you can program a lot of other parts using
the same hardware interface. So why not integrate with some programming software
that can take advantage of that fact?

BAJ

2006\01\30@003558 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 12:16:59PM +0800, Xiaofan Chen wrote:
> On 1/30/06, James Newton, Host <.....jamesnewtonKILLspamspam.....piclist.com> wrote:
>
> > It really seems to me that it would be nice to have a very simple
> > programming circuit that could load at least one or two types of blank PIC
> > chip.
>
> If you want simple programmers, what is wrong with those
> JDM/tait coupled with pikdev (Linux) or WinPIC/IC-Prog/WinPIC800/PICPGM/...?
> Why need another one?

As I explained in a earlier post that it's getting more difficult to find machines
with the appropriate ports. My last laptop had parallel and serial. My current
laptop has only serial. I'm pretty sure my next laptop will be USB only.

Serial interfaces are available in native form and USB. However, many native
serial interfaces have voltage issues, making JDM style programmer operate
erratically. USB to serial adapters often do not have tight synchronization
between modem control pins and JDM style programmers need tight synchro between
modem control pins and TX to operate properly.

So Tait style parallel programmers don't have interfaces to connect to and
serial programmers cannot be guaranteed the required environment to operate
properly.

Hence another option is needed if someone is interested in just wiggling some
pins from their PC just enough to get a part programmed to bootstrap something
else.

That's the niche that this device (I'm not sure I would want to characterize
it as a programmer) resides. While USB to serial cables have some issues, TX
generating a serial signal with proper timing isn't one of them.

BAJ

2006\01\30@005457 by Xiaofan Chen

face picon face
On 1/30/06, Byron A Jeff <EraseMEbyronspam_OUTspamTakeThisOuTcc.gatech.edu> wrote:
> So Tait style parallel programmers don't have interfaces to connect to and
> serial programmers cannot be guaranteed the required environment to operate
> properly.
>
> Hence another option is needed if someone is interested in just wiggling some
> pins from their PC just enough to get a part programmed to bootstrap something
> else.
>
> That's the niche that this device (I'm not sure I would want to characterize
> it as a programmer) resides. While USB to serial cables have some issues, TX
> generating a serial signal with proper timing isn't one of them.
>

If you want USB, PICkit 2 or GTP USB Lite will be a better solution IMHO.

Adding the cost of a USB to serial converter to a simple programmer
will bring the cost similar to GTP USB Lite or even PICkit 2. I know quite
some people do have USB to serial converter but other may not have. For
one I do not have any USB to serial converter.

Take note that GTP USB Lite is very similar to Wisp628A but it is using
USB port to power up the programmer. It will be actually quite cheap to
build. The software is closed source though but the hardware is quite
simple. It supports many PICs and even dsPICs using WinPIC800.

http://www.hobbypic.com/index.php?option=com_content&task=view&id=12&Itemid=34

Regards,
Xiaofan

2006\01\30@012251 by Bob Blick

face picon face

> Hence another option is needed if someone is interested in just wiggling
> some
> pins from their PC just enough to get a part programmed to bootstrap
> something
> else.

Is there any standardization in USB-to-parallel converters? Because it
seems to me that "wiggling", in general, is a useful thing. Not just for
pic programmers, but for JTAG, testing LCDs, etc. And sevral pins of
wiggling, not just two or three.

So the parallel port vacuum will get stronger and stronger until something
fills it.

Two years ago when I bought my laptop, I also bought a pcmcia parallel
port card. It was expensive, but it's a real parallel port. I imagine in
the future someone will make a USB version that takes hold in the
marketplace and be more affordable.

Cheerful regards,

Bob


2006\01\30@012412 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 01:54:57PM +0800, Xiaofan Chen wrote:
> On 1/30/06, Byron A Jeff <byronspamspam_OUTcc.gatech.edu> wrote:
> > So Tait style parallel programmers don't have interfaces to connect to and
> > serial programmers cannot be guaranteed the required environment to operate
> > properly.
> >
> > Hence another option is needed if someone is interested in just wiggling some
> > pins from their PC just enough to get a part programmed to bootstrap something
> > else.
> >
> > That's the niche that this device (I'm not sure I would want to characterize
> > it as a programmer) resides. While USB to serial cables have some issues, TX
> > generating a serial signal with proper timing isn't one of them.
> >
>
> If you want USB, PICkit 2 or GTP USB Lite will be a better solution IMHO.

Xiaofan,

All well covered territory. Suffice it to say that I find utility in having
a programmer that can be put together with junk box part. I've built every
PIC programmer I've used except for a PS+1 I got 10 years ago for attending
a local Mchip event.

> Adding the cost of a USB to serial converter to a simple programmer
> will bring the cost similar to GTP USB Lite or even PICkit 2. I know quite
> some people do have USB to serial converter but other may not have. For
> one I do not have any USB to serial converter.

Point taken. But a USB to serial converter is a common technology item nowadays.
One can drop in the CompUSA or the WalMart and pick one up. They are not single
sourced and made of unobtanium.

> Take note that GTP USB Lite is very similar to Wisp628A but it is using
> USB port to power up the programmer. It will be actually quite cheap to
> build. The software is closed source though but the hardware is quite
> simple. It supports many PICs and even dsPICs using WinPIC800.
>
> http://www.hobbypic.com/index.php?option=com_content&task=view&id=12&Itemid=34

Yes but it's just as subject to the chicken and egg problem as everything else
as it uses an 18F2550 as an interface.

That's why I'm trying to get away from the concept of this being a programmer.
I agree we don't really need another programmer. However I do believe that we
need a replacement for the venerable parallel and serial port programmers that
could program a chip without having to have programmed chips to do the job.

I believe there is still a niche for bootstrapping hardware, and especially simple
bootstrapping hardware that one can piece together from junkbox parts in a short
period of time.

BAJ

2006\01\30@012627 by James Newtons Massmind

face picon face
> If you want USB, PICkit 2 or GTP USB Lite will be a better
> solution IMHO.
>
> Adding the cost of a USB to serial converter to a simple
> programmer will bring the cost similar to GTP USB Lite or
> even PICkit 2. I know quite some people do have USB to serial
> converter but other may not have. For one I do not have any
> USB to serial converter.
>
> Take note that GTP USB Lite is very similar to Wisp628A but
> it is using USB port to power up the programmer. It will be
> actually quite cheap to build. The software is closed source
> though but the hardware is quite simple. It supports many
> PICs and even dsPICs using WinPIC800.


<song> The day... The haaaaaakerrrrrs died... </song>

Oh well...

1. Serial so it will work on all available compters, terminals, PDAs, etc...

2. No software or web server based software so the OS doesn't matter.

3. Actually shows the user what the heck is going on rather than "magic
happens in this program and some signals go into the PIC and wow! Presto!
It's programmed"

4. Allows a bootloader (open source) to be loaded into the PIC so that
future loads are faster, still don't require software, etc...

5. Bootload programmer software for what ever open source programmer you
want for other PICs and use whatever software.

But at least once, you had some idea of what signals were actually being
applied to the PIC....


Ok, enough said. I'll let it die now.

---
James.


2006\01\30@013208 by Byron A Jeff

face picon face
On Sun, Jan 29, 2006 at 10:22:51PM -0800, Bob Blick wrote:
>
> > Hence another option is needed if someone is interested in just wiggling
> > some
> > pins from their PC just enough to get a part programmed to bootstrap
> > something
> > else.
>
> Is there any standardization in USB-to-parallel converters?

Nope. Their driver presents a printing interface, not a pin wiggling one.


> Because it
> seems to me that "wiggling", in general, is a useful thing. Not just for
> pic programmers, but for JTAG, testing LCDs, etc. And sevral pins of
> wiggling, not just two or three.

Correct.

> So the parallel port vacuum will get stronger and stronger until something
> fills it.

This is why I'm pursuing the stopgap. Any old PIC can easily serve as a multipin
serial to parallel interface. But you have to be able to program the part.

> Two years ago when I bought my laptop, I also bought a pcmcia parallel
> port card. It was expensive, but it's a real parallel port. I imagine in
> the future someone will make a USB version that takes hold in the
> marketplace and be more affordable.

Interesting idea. However, with parts like the FTDI 245 parallel, or even
18F USB PICS, that conversion isn't going to be impossible. But espeically with
the PICs it'll be kind of difficult to bootstrap if you have to obtain a
USB PIC programmer for the sole purpose of dumping code into the part.

I'm admittedly biased because I don't see PIC programmers beyond being tools
used to dump bootloaders into the part so I can get to work. From that again
admittedly warped world view, finding something to fill to code dumper niche
cheaply, simply, and with readily available parts is important to me. The
Trivial programmers have filled this need in the parallel realm for the last
5 years or so. Now I think it's time to branch out to serial and USB. But
USB is flat too complicated to interface to. So the USB to serial interface
serves as a building block that can be used for the code dumper and reused
as a serial bootloader interface.

BAJ

2006\01\30@013518 by Byron A Jeff

face picon face
On Sun, Jan 29, 2006 at 10:26:19PM -0800, James Newtons Massmind wrote:
{Quote hidden}

Yes.

>
> 2. No software or web server based software so the OS doesn't matter.

I could buy that. My preference is open source software that can be ported
to the required platform.

> 3. Actually shows the user what the heck is going on rather than "magic
> happens in this program and some signals go into the PIC and wow! Presto!
> It's programmed"

Yes and no. Good from an educational standpoint. Not so good for the hobbist
that just wants to get a job done.

> 4. Allows a bootloader (open source) to be loaded into the PIC so that
> future loads are faster, still don't require software, etc...

Bingo. That's the primary purpose. It can even be used to bootstrap a
traditional programmer if need be for parts who don't support bootloading.

>
> 5. Bootload programmer software for what ever open source programmer you
> want for other PICs and use whatever software.

Yup.

> But at least once, you had some idea of what signals were actually being
> applied to the PIC....
>
>
> Ok, enough said. I'll let it die now.

Thanks for the insight.

BAJ

2006\01\30@015828 by Wouter van Ooijen

face picon face
> Again, the point is to not require any programming software,

why is that a (n important) point?

Wouter van Ooijen

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


2006\01\30@034035 by Xiaofan Chen

face picon face
On 1/30/06, James Newtons Massmind <@spam@jamesnewtonKILLspamspammassmind.org> wrote:
{Quote hidden}

I've replied in the previous email. I repeat it here.

"If you want simple programmers, what is wrong with those
JDM/tait coupled with pikdev (Linux) or WinPIC/IC-Prog/WinPIC800/PICPGM/...?
Why need another one?"

> 2. No software or web server based software so the OS doesn't matter.

What do you mean by "no software"? Why is that a requirement?

Wisp628A/xwisp2 is quite good so that
most OS are supported (Linux/Windows/FreeBSD/OS2/Mac OS). You
can develop PDA based version if you want.

> 3. Actually shows the user what the heck is going on rather than "magic
> happens in this program and some signals go into the PIC and wow! Presto!
> It's programmed"

So you expect all the use to study the complicated programming
specifications? Apparently it is more complicated than many people
think.

I will say those who really understands "what the heck is going on" when
programming a PIC will understand that it is not simple at all.

> 4. Allows a bootloader (open source) to be loaded into the PIC so that
> future loads are faster, still don't require software, etc...


> 5. Bootload programmer software for what ever open source programmer you
> want for other PICs and use whatever software.
>
> But at least once, you had some idea of what signals were actually being
> applied to the PIC....

I do not understand what you mean by "no software"? You still needs
a host downloading software.

I do not say that simple programmer is of no use. I just say the existing
programmers are good enough at least in the aspect of hardware. We have
serial based JDM/Wisp628A/EasyProg/PS+ and parallel based LVP/Tait/EPIC+
and USB based PICkit 2/GTP USB Lite/Kits 1xx/ICD2.

If one wants to develop another simple programmer for the community,
I guess it will be better to spend the time on improving existing firmware
and PC software.

For example, it is a challenge to port Wisp628A to dsPIC and base line PICs.
It is a challenge to port EasyProg to Linux. It is challenge to port EasyISP to
newer protocols. It is a challenge to improve PiKdev (Linux) to support more
PICs or even dsPICs under Linux. It is a challenge to continue the
extending the chip support of PICkit 2 under Linux. It is challenge to support
ICD2 under Linux with PIKlab. There are so many things which can be done.

> Ok, enough said. I'll let it die now.
>

I do not understand your rant at all.

Regards,
Xiaofan

2006\01\30@040323 by Wouter van Ooijen

face picon face
> "If you want simple programmers, what is wrong with those
> JDM/tait coupled with pikdev (Linux) or
> WinPIC/IC-Prog/WinPIC800/PICPGM/...?
> Why need another one?"

The gradual extinction of (real, not useb-converted) parallel and serial
ports.

> I do not understand what you mean by "no software"? You still needs
> a host downloading software.

Not if the "source" file is in such a format that it can be copied
directly to the serial port. Unfortunatley this requires some hardware
that takes over the timing control from the now absent software.

> I do not understand your rant at all.

I do understand, but I don't think there is a good solution. IMHO good
means:
- works with usb-to-serial (or parallel) converters
- requires none or very simple hardware (IMHO what James shows is not
simple enough)
- (optionally - I think this is less important) requires no host
software

Wouter van Ooijen

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


2006\01\30@040503 by Xiaofan Chen

face picon face
On 1/30/06, Byron A Jeff <KILLspambyronKILLspamspamcc.gatech.edu> wrote:

> Yes but it's just as subject to the chicken and egg problem as everything else
> as it uses an 18F2550 as an interface.
>
> That's why I'm trying to get away from the concept of this being a programmer.
> I agree we don't really need another programmer. However I do believe that we
> need a replacement for the venerable parallel and serial port programmers that
> could program a chip without having to have programmed chips to do the job.
>
> I believe there is still a niche for bootstrapping hardware, and especially simple
> bootstrapping hardware that one can piece together from junkbox parts in a short
> period of time.
>

Hi BAJ,

Thanks for your explanation and now I understand your point to "develop
a replacement for the venerable parallel and serial port programmers that
could program a chip without having to have programmed chips to do the job".

Yes I agree with you that this is good to have. It only needs to support some
popular MCUs like 16F628A/648A/16F88/18F452/18F2550 to support many
popular intelligent programmers. It only needs to support some popular
hobby PICs to be useful. And I guess it could tap other software like
PiKdev/PICPGM/... to support many other PICs as well.

Regards,
Xiaofan

2006\01\30@041135 by Xiaofan Chen

face picon face
On 1/30/06, Byron A Jeff <RemoveMEbyronTakeThisOuTspamcc.gatech.edu> wrote:
> On Sun, Jan 29, 2006 at 10:26:19PM -0800, James Newtons Massmind wrote:
>
> > 4. Allows a bootloader (open source) to be loaded into the PIC so that
> > future loads are faster, still don't require software, etc...
>
> Bingo. That's the primary purpose. It can even be used to bootstrap a
> traditional programmer if need be for parts who don't support bootloading.
>

Yes I agree that booloader can be a good option and a simple code
dumper like TLVP does have its usage.

Take note most new PIC16F device will be "standard Flash" PICs and
will not support bootloading. Actually there will be more and more
"standard Flash" PICs (16F and 18F) which do not support bootloading
as Microchip is pushing low cost PICs.

Regards,
Xiaofan

2006\01\30@041154 by Marcel van Lieshout

flavicon
face
Forest Electronics Development has some nice, no too expensive programmers.
I use the pikey and am very pleased with it.
http://www.fored.co.uk

Marcel

Wouter van Ooijen wrote:
{Quote hidden}

2006\01\30@052246 by Wouter van Ooijen

face picon face
> Forest Electronics Development has some nice, no too
> expensive programmers.
> I use the pikey and am very pleased with it.

The cheapest is E 66, so I don't think these programmers are relevant to
this discussion. This discussion is about what you can build with stuff
from your junkbox.

Wouter van Ooijen

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


2006\01\30@061424 by Gerhard Fiedler

picon face
Byron A Jeff wrote:

>> Two years ago when I bought my laptop, I also bought a pcmcia parallel
>> port card. It was expensive, but it's a real parallel port. I imagine
>> in the future someone will make a USB version that takes hold in the
>> marketplace and be more affordable.
>
> Interesting idea. However, with parts like the FTDI 245 parallel, or
> even 18F USB PICS, that conversion isn't going to be impossible. But
> espeically with the PICs it'll be kind of difficult to bootstrap if you
> have to obtain a USB PIC programmer for the sole purpose of dumping code
> into the part.

This was an interesting discussion. Let me add a thought here... This about
someone starting a hobby, right? When you're starting with electronics, you
need to buy some tools and you don't have a junk box yet, so most of the
parts you'll need you have to buy, too. It's assumed that you have a
computer, or else you'll have to buy that one, too. So maybe we just
consider a pre-programmed PICs (programmer core, or a port wiggler) or a
parallel port adapter one of those tools you buy?

OTOH (and I need to add here that I don't have a clue about the programming
specs -- a detail I never was too curious about :) if the programming spec
is static or at least has wide enough timing specs so that it can be done
/very/ slow, the modem control signals of a USB-to-serial adapter should
work. They can't be relied upon for quick timing, but they are probably
good enough for timing in the tens or hundreds of milliseconds. Programming
one byte per second is good enough for such a bootstrapper programmer.
This, controlled by a PC software written in a highly portable language,
could do it, couldn't it? Of course this violates James's "no software"
condition, but I'm not sure how important it is. "Highly portable" should
be good enough. And probably the only parts that are platform-dependent are
some means to control timing in the 100s of ms and how to wiggle the modem
control lines. If the programming specs allow such slow programming...

Gerhard

2006\01\30@072605 by olin piclist

face picon face
James Newton, Host wrote:
> Ok then, how about an LVP programmer that uses only non-programmed
> components and takes a stream from a serial port like Tony's ASCII
> programmer. Perhaps the clock signal could be developed without RC
> circuits.

Why is that better than a high voltage programmer which can always program
the chip regardless of how the LVP bit is set?

> Again, the point is to not require any programming software,

But why?  There clearly needs to be *some* software between the disk and the
serial port (or whatever port), so why not let that software do a few other
useful things.  Requiring no software seems backwards.  There is going to be
complexity somewhere.  It makes sense to push that complexity onto the host
where developing it is easier, there are essentially no speed and memory
constraints, and the incremental cost is basically zero.

When I design a programmer I think about the higherarchy of host software,
firmware, and hardware.  You want to push complexity as much as possible to
the beginning of that chain except as required to meet the performance and
capability goals.  I have just revised my programmer host protocol again to
put less burden on the programmer in a few areas.  When I originally started
that several years ago, I was envisioning the programmer performing some
operations at a higher level on its own.  These were never implemented and I
later realized that they can be managed from the host without speed penalty.
The programmer firmware performs the lower level operations that the host
can't do fast enough, but as much as possible the host does the "thinking"
and high level control.

> but rather
> use a data file that loads a bootloader or like that. The data file
> only needs to be developed once, but having server based software for
> turning a hex file into such a datafile would be very cool as well.

The data file needs to be developed at least once for each HEX file.  You'll
probably do this with a program.  Given that that program will execute
instantaneously in human terms, why not run the program each time the data
file is needed from the HEX file.  Then you can run it with any HEX file at
any time.  Then you realize that since you can make the data file for free
whenever you want it, you don't need to save it.  You're making a temporary
data file on demand.  It's really just a data stream, since it's not saved
anymore.  So now you have a program that reads a HEX file on one side and
writes to a serial port on the other side to "convert" the HEX file
information into whatever is required for the low-complexity programmer to
write it into the target PIC.  Sound familiar?

> It really seems to me that it would be nice to have a very simple
> programming circuit that could load at least one or two types of blank
> PIC chip.  And it isn't like these chips stop being made. You can still
> buy 16F84's and you can still use a 16F84 to make a programmer that
> will program just about anything else. Right?

So how about a 16F648A, which is actually cheaper than a 16F84?  The
EasyProg (http://www.embedinc.com/easyprog) isn't the absolute simplest
circuit because robustness and flexibility were also a concerns, but it's
not real complicated either.  It would be easy to pare down the EasyProg
circuit if you didn't care about variable Vdd and didn't try to accomodate
multiple target footprints in the ZIF socket.  If you do that, you can even
start with the EasyProg firmware and strip some things out.  Many of the
protocol commands are now optional that weren't when the EasyProg was
designed, so the existing host software will just work as long as the
firmware adheres to any of the published protocol spec versions.  You could
even program dsPICs with it.


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

2006\01\30@074400 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> This was an interesting discussion. Let me add a thought
> here... This about someone starting a hobby, right? When
> you're starting with electronics, you need to buy some
> tools and you don't have a junk box yet, so  most of the
> parts you'll need you have to buy, too.


Right, I was thinking along the same lines.

Are you going to use a "no-parts"/"no-cost"
soldering-iron also ?? If not, why is it that the
*programmer* has to be of that kind ?

There are very few hobbies at all that are
"no-cost"...

Regards,
Jan-Erik.



2006\01\30@093151 by Wouter van Ooijen

face picon face
>> Ok then, how about an LVP programmer that uses only non-programmed
>> components and takes a stream from a serial port like Tony's ASCII
>> programmer. Perhaps the clock signal could be developed without RC
>> circuits.
>
> Why is that better than a high voltage programmer which can
> always program the chip regardless of how the LVP bit is set?

The hardware can be simpler.

>> Again, the point is to not require any programming software,
>
> But why?  

Probably to support the widest range of PC platforms.

> There clearly needs to be *some* software between
> the disk and the serial port (or whatever port)

Yes, but that software does not need to be on the users PC: the author
could translate the .hex file to something that can be streamed directly
out of the serial or parallel port.

Note that I don't fully agree with James' ideal, but I can see his
points.

Wouter van Ooijen

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


2006\01\30@113139 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 07:27:50AM -0500, Olin Lathrop wrote:
> James Newton, Host wrote:
> > Ok then, how about an LVP programmer that uses only non-programmed
> > components and takes a stream from a serial port like Tony's ASCII
> > programmer. Perhaps the clock signal could be developed without RC
> > circuits.
>
> Why is that better than a high voltage programmer which can always program
> the chip regardless of how the LVP bit is set?

I think Wouter believes that creating a switched high voltage Vpp interface
is a bit of a challenge. He's also concerned that there will be problems if
the user has to hand switch the interface. I would literally create a LM317
based regulated 13V and then tie a SPST toggle between the resistor voltage
divider point and GND. This will switch between 13V and 1.25V. To complete
the circuit I would current limit the LM317 output using a 100 ohm resistor
and then tie the same switch between MCLR and GND. That way when the switch
is off you have 13V with a 130 mA output and when the switch is on,
MCLR is grounded with the junction point of MCLR sinking the 1.25V @ 1.25 mA.

>
> > Again, the point is to not require any programming software,
>
> But why?

I'm not sure why James thinks this is useful. By using traditional programming
software, such a circuit could potentially program any PIC.

>  There clearly needs to be *some* software between the disk and the
> serial port (or whatever port), so why not let that software do a few other
> useful things.  Requiring no software seems backwards.  There is going to be
> complexity somewhere.  It makes sense to push that complexity onto the host
> where developing it is easier, there are essentially no speed and memory
> constraints, and the incremental cost is basically zero.

Bingo. In fact if you have programming software that separates the programming
and hardware interfaces, like pikdev, then adding new hardware is nothing more that
writing a new hardware interface class. That's what I was doing for testing my
555 based code dumper.

{Quote hidden}

While I agree on all points, the point I would throw in James' defense is that I
am somewhat interested in the OS neutral aspect of performing the conversion then
dumping the file. But what Olin proposes can be accomplished simply by having
at least one Open Source programmer. Then the code would be portable to other
platforms such as a PDA.


My lingering question is if this type of code dumper meets its intended occasional
use, then how important is it to have verification of the code that is dumped.
Is unit testing with a blinking LED type program sufficient to show that the
code dumper is completing its one way dump? This would then be followed by the
target dump. I ask because this is the true dividing line between just dumping
a file to the serial port and using traditional programming software.

At the end of the day gentlemen, there's no reason not to do both. James' output
file is nothing more than an intermedate representation of the output of a
traditional programmer. So it would be trivial to direct the serial output
to a file instead of sending it directly to the serial port.

{Quote hidden}

The only argument against again is the probability that the programming software
you describe is somehow OS dependant. The data stream can be dump using
Hypertem, or minicom, or a Palm terminal emulator, or kermit, or whatever the
Mac is currently using for serial interfaces. OS neutral. Programming software
generally is not OS neutral, which means someone has to take the time to port
to each architecture. And when the target to be dumped is really useful, like
a bootloader, there can be some value in having the intermediate data stream.
No matter the platform, you can then get the file, dump it, and be done with it.

Gotta go, I'll tackle the rest later.

BAJ

2006\01\30@122615 by James Newtons Massmind

face picon face
> > This was an interesting discussion. Let me add a thought
> here... This
> > about someone starting a hobby, right? When you're starting with
> > electronics, you need to buy some tools and you don't have
> a junk box
> > yet, so  most of the parts you'll need you have to buy, too.
>
>
> Right, I was thinking along the same lines.
>
> Are you going to use a "no-parts"/"no-cost"
> soldering-iron also ?? If not, why is it that the
> *programmer* has to be of that kind ?
>
> There are very few hobbies at all that are "no-cost"...

All true. But that misses the point, which is hard to see if you aren't a
"hacker." (in the true sense of the word)

I have a t-shirt that shows the view over a set of motorcycle handlebars and
it says "if you don't ride, you wouldn't get it." I guess this is the same
sort of thing. There is a joy in understanding something from the very
bottom to the top. A rush in being able to mentally zoom from the level of
electrons, through simple electricity, through logic gates, through signal
timing, through serial data streams, through programming commands to the
PIC, through the data being loaded into the PIC, through the PIC running the
code, all the way up to the physical level of watching the LED blink to
indicate that your code is running. It is like this video:
http://video.google.com/videoplay?docid=-5555313278261147278 An excellent
documentary about powers of 10 and the true scale of the universe. Well
worth the 8 minutes or so.

With an application program on the PC, mac, PDA, whatever, part of that zoom
is broken. I guess if the software is open source and well documented... But
it is better if only the minimum programming commands are included and the
simplest change from the original HEX file to the data sent to the
programmer. It is best if you can see how the datastream being sent to the
programmer is actually assembled.

And this is only from my point of view, and maybe from the viewpoint of most
"hackers" (in the true sense of the word) so yes, I understand it doesn't
make sense to most people.

---
James.


2006\01\30@125118 by James Newtons Massmind

face picon face
> > > Again, the point is to not require any programming software,
> >
> > But why?
>
> I'm not sure why James thinks this is useful. By using
> traditional programming software, such a circuit could
> potentially program any PIC.

Mostly I see an educational / hacker benefit. I've explained the hacker part
more in a prior post. But I just had another idea that might be more....
Reasonable and easy to understand.

How about if the output of the programming software did not need to
immediately go to the programmer? If it could be saved in a file and then
simply copied out the serial port at a later date?

This could be very useful for

- Remote updates, (especially on chips that don't support bootloading)

- Bootstrapping simple devices where the same datafile could be used again
and again without need of the programming software except for the first
time.

- Educational interest (see  the actual signal being sent to the PIC without
expensive test equipment) study the timing of at least one simple case so
you understand what is going on in general.

- Extreme cross platform support (server based programming software). You
could program PICs from your PDA, Mainframe, AS400, serial print server,
anything with a serial port.

- Cool Hacker factor (maybe I'm the only one who sees that <grin>)

And it would still allow normal operation when that intermediate transport
was not needed. The programming software could be directly connected to the
programmer, or separated from it, either way.

Does that make any more sense?

---
James.


2006\01\30@132752 by Wouter van Ooijen

face picon face
> How about if the output of the programming software did not need to
> immediately go to the programmer? If it could be saved in a
> file and then simply copied out the serial port at a later date?

how would you preserve the timing?

Wouter van Ooijen

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


2006\01\30@140226 by olin piclist

face picon face
James Newtons Massmind wrote:
> How about if the output of the programming software did not need to
> immediately go to the programmer? If it could be saved in a file and
> then simply copied out the serial port at a later date?

This means there is no chance of any readback from the target PIC.  In
theory it would work if everything went right, but you wouldn't know if it
didn't until you tried to run the code.  Diagnosing a problem with this
setup could be very frustrating, especially for a newbie for whom this
programmer is supposed to be aimed at.


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

2006\01\30@151448 by William Chops Westfield

face picon face
> Again, the point is to not require any programming software,
>
So, does this reduce to a request that flash PICs ship with a
serial bootloader of some kind already installed in the flash?

BillW

2006\01\30@152156 by Wayne Topa

flavicon
face
Marcel van Lieshout(spamBeGonemarcelspamBeGonespamhmcs.nl) is reported to have said:
> Forest Electronics Development has some nice, no too expensive programmers.
> I use the pikey and am very pleased with it.
> http://www.fored.co.uk

Interesting priceing!
£40.00 ($170)
£45.00 ($80)

???

I'd rather stay with the junkbox then go with their
conversion prices.

WT
--
Build a system that even a fool can use, and only a fool will use it.
_______________________________________________________

2006\01\30@155032 by James Newtons Massmind

face picon face
> > How about if the output of the programming software did not need to
> > immediately go to the programmer? If it could be saved in a
> file and
> > then simply copied out the serial port at a later date?
>
> how would you preserve the timing?
>
> Wouter van Ooijen


1200N71

The timeing on the ASCII programmer is implicit in the rate of data falling
out the end of the serial port. So from the DOS command line I guess you
would have to both set the port with the mode command and then copy the
file. Not sure in Linux, other hosts have ways of setting the baud rate,
etc... And then sending out the data.

---
James.


2006\01\30@162807 by Gerhard Fiedler

picon face
James Newtons Massmind wrote:

>> Are you going to use a "no-parts"/"no-cost" soldering-iron also ?? If
>> not, why is it that the *programmer* has to be of that kind ?
>
> All true. But that misses the point, which is hard to see if you aren't
> a "hacker." (in the true sense of the word)
>
> I have a t-shirt that shows the view over a set of motorcycle handlebars
> and it says "if you don't ride, you wouldn't get it." I guess this is
> the same sort of thing. There is a joy in understanding something from
> the very bottom to the top.

I think I understand this, to some degree... like many here, having worked
on many levels of computing, from electronics upwards to development of
multi-tier server architectures, it's a special delight knowing, when
working on the umpteenth layer up in the heights, that I /could/ go down
there :)

> With an application program on the PC, mac, PDA, whatever, part of that
> zoom is broken. I guess if the software is open source and well
> documented...

I carefully disagree. I think such an async serial programmer may be a cool
hack, just for the heck of it; I can see that. But it's also somewhat a
violation of the programming algorithm, and in that not exactly instructive
for a beginner, and also not helping the (my) zoom. A cleanly written and
well documented open source application that implements the pin wiggling as
described in the programming specs and shows a few good programming
practices and provides, among others, a template for how to create
multi-platform command line serial port access applications is, IMO, a
/lot/ more instructive and -- for me at least -- does not break the zoom.
To the contrary: it probably would add a bit to the depth of zoom of most
of us.

<highly exaggerated> I think brainlessly downloading a byte stream from a
web site and then copying that out the serial port using commands copied
from a web page on that site does not contribute to any beginner's
education, nor to any hacker's delight or increase the depth of any zoom :)
<back to normal>

Gerhard

2006\01\30@163257 by Wouter van Ooijen

face picon face
>> how would you preserve the timing?
>
> 1200N71
>


That's fine for the single output line, but that implies some (limited)
'intelligence' on the other side of the serial port. IMHO that spoils
the idea.

Wouter van Ooijen

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


2006\01\30@184554 by Howard Winter

face
flavicon
picon face
Wayne,

On Mon, 30 Jan 2006 15:21:51 -0500, Wayne Topa wrote:

{Quote hidden}

Where are you seeing this?  On the "PIC Programmers" page they have:

£40 ($75)
£35 ($68)
£95 ($171)
£25 ($45)...

Looks pretty consistent to me!  :-)

Cheers,


Howard Winter
St.Albans, England


2006\01\30@190734 by Tomas Larsson

flavicon
face
There seems to be a typoo in one of the pages.

With best regards

Tomas Larsson
Sweden

Verus Amicus Est Tamquam Alter Idem

> {Original Message removed}

2006\01\30@193043 by Xiaofan Chen

face picon face
On 1/31/06, Gerhard Fiedler <RemoveMElistsspamTakeThisOuTconnectionbrazil.com> wrote:
>
> <highly exaggerated> I think brainlessly downloading a byte stream from a
> web site and then copying that out the serial port using commands copied
> from a web page on that site does not contribute to any beginner's
> education, nor to any hacker's delight or increase the depth of any zoom :)
> <back to normal>
>
> Gerhard

I can not agree more even though you put it under "highly exaggerated".

Regards,
Xiaofan

2006\01\30@220709 by Wayne Topa

flavicon
face
Howard Winter(HDRWEraseMEspam.....H2Org.demon.co.uk) is reported to have said:
> Wayne,
>
> On Mon, 30 Jan 2006 15:21:51 -0500, Wayne Topa wrote:
>
> > Marcel van Lieshout(EraseMEmarcelspamhmcs.nl) is reported to have said:
> > > Forest Electronics Development has some nice, no too expensive programmers.
> > > I use the pikey and am very pleased with it.
> > > http://www.fored.co.uk
> >
> > Interesting priceing!
> > £40.00 ($170)
> > £45.00 ($80)
> >
> > ???
> >
> > I'd rather stay with the junkbox then go with their
> > conversion prices.
>
> Where are you seeing this?  On the "PIC Programmers" page they have:

http://www.fored.co.uk/html/program_debug.html

USP+ Programmer
including in-circuit programming £40.00 ($170)

PIC Development Board
Supports all 16/18 40 pin devices includes programmer £45.00 ($80)

>
>  £40 ($75)
>  £35 ($68)
>  £95 ($171)
>  £25 ($45)...
>
> Looks pretty consistent to me!  :-)

I guess it depends on which page you order from.
I'll pass.

WT

--
Error reading FAT record: Try the SKINNY one? (Y/N)
_______________________________________________________

2006\01\31@011903 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 10:30:52PM +0100, Wouter van Ooijen wrote:
> >> how would you preserve the timing?
> >
> > 1200N71
> >
> That's fine for the single output line, but that implies some (limited)
> 'intelligence' on the other side of the serial port. IMHO that spoils
> the idea.

Wouter, I think you missed the idea. Let me repeat. Take a look at my TBS555
schematic for reference:

http://www.finitesite.com/d3jsys/tbs555

You can ignore the RX stuff in the top right corner of the page. I'm still
trying to work that through. It's also unnecessary for a black hole TX out
version of this circuit.

The beginning of the start bit triggers both 555 circuits. The left 555 is
tuned to about a 1/2 character time. The right one is tuned towards the end
of the character time bleeding into the stop bit. The output of the right 555
drives the emitter of the transistor driving the 555 triggers to 5V turning
the transistor off. So both 555s end up being edge triggered and will time
out at the same time no matter how TX wiggles after the trigger.

So in the end only the RC timing is the "intelligence" on the other side of
the serial port. The left 555 will always time out in the center of the
character transmitted and will clock the value of TX at that time. So a
character with leading zeros will clock a zero and a character with leading
ones will clock a one in the PIC.

Simple. And only rough tuning on the 1/2 and full character time are required

I tested this circuit at 9600 BPS. It works fine.

It's the RX side I have not yet figured out. The objective is to create
a structured character that reflects the bit transmitted by TX or by the
PIC through the PIC data line. The parameters are that it needs to have a
valid start bit, can only be a character width in size, and accurately
reflect the current TX/PD bit. It's still a work in progress.

But at the end of the day, the only "intelligence" is the RC timing of the
two 555s.

BAJ

2006\01\31@012015 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 02:03:26PM -0500, Olin Lathrop wrote:
> James Newtons Massmind wrote:
> > How about if the output of the programming software did not need to
> > immediately go to the programmer? If it could be saved in a file and
> > then simply copied out the serial port at a later date?
>
> This means there is no chance of any readback from the target PIC.  In
> theory it would work if everything went right, but you wouldn't know if it
> didn't until you tried to run the code.  Diagnosing a problem with this
> setup could be very frustrating, especially for a newbie for whom this
> programmer is supposed to be aimed at.

Agreed. That's why I was working on RX feedback on my code dumper.
Also I planned to use traditional programming software to talk to it so
that it could send back feedback.

BAJ

2006\01\31@015126 by Wouter van Ooijen

face picon face
>> That's fine for the single output line, but that implies
>> some (limited)
>> 'intelligence' on the other side of the serial port. IMHO
>> that spoils the idea.
>
> Wouter, I think you missed the idea. Let me repeat. Take a
> look at my TBS555
> schematic for reference:
> http://www.finitesite.com/d3jsys/tbs555

That's what I call (limited) 'intelligence' (comparable to a BEAM
robot).

> Simple.

That's wehere we disagree (too).

Wouter van Ooijen

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


2006\01\31@043916 by Tomas Larsson

flavicon
face
{Quote hidden}

Actually not, if you order from the order-page you get the right price.

With best regards

Tomas Larsson
Sweden

Verus Amicus Est Tamquam Alter Idem



'[PIC] [gnupic] noob's 1st ques'
2006\02\02@064803 by Alan B. Pearce
face picon face
>Finally one could build a programmer with automatic Vpp
>switching. Generally USB to serial converters do have
>working modem control signals. However, they are generally
>not synchronized to the TX stream. So you cannot have the
>precise timing control that programmers like JDM require.
>But if the modem control signal is switchable at all,
>you can use it to switch Vpp.

Surely you could loop the modem control signal back to one of the modem flag
signals, so that you do not start transmitting data until you see that the
control signal has changed state.

>I'm still debating how important verification is for the
>bootloader dumper. Should it be as simple as testing with
>a blinky LED and then dump a self verifying bootloader
>to the part?

How about having a blinky LED program as an inherent part of the bootloader
download (but the blinky LED would load in the "user" space), and part of
the verification is the blinky led program does a CRC check of the
downloaded bootloader, and flashes an appropriate go/nogo code on running.
When the bootloader downloads a program it overwrites the blinky led code -
which has done its job now anyway.

2006\02\02@070206 by Byron A Jeff

face picon face
On Thu, Feb 02, 2006 at 11:47:59AM -0000, Alan B. Pearce wrote:
> >Finally one could build a programmer with automatic Vpp
> >switching. Generally USB to serial converters do have
> >working modem control signals. However, they are generally
> >not synchronized to the TX stream. So you cannot have the
> >precise timing control that programmers like JDM require.
> >But if the modem control signal is switchable at all,
> >you can use it to switch Vpp.
>
> Surely you could loop the modem control signal back to one of the modem flag
> signals, so that you do not start transmitting data until you see that the
> control signal has changed state.

That's an idea worth examining. However it'll slow downloading with a JDM
style programmer to a crawl as supposedly these flags update on the order
of milliseconds.

{Quote hidden}

That's a good idea. I'll keep it in my back pocket.

THanks,

BAJ

2006\02\02@080635 by Alan B. Pearce

face picon face
>> Surely you could loop the modem control signal back to one of the modem
flag
>> signals, so that you do not start transmitting data until you see that
the
>> control signal has changed state.
>
>That's an idea worth examining. However it'll slow downloading with a JDM
>style programmer to a crawl as supposedly these flags update on the order
>of milliseconds.

Well I was figuring it only needed to be checked at the beginning of a
programming run. Turn on Vpp, check it is on, and then hose out the data in
the manner you suggest. Surely you do not check Vpp with every byte?

2006\02\02@081057 by Byron A Jeff

face picon face
On Thu, Feb 02, 2006 at 01:06:10PM -0000, Alan B. Pearce wrote:
> >> Surely you could loop the modem control signal back to one of the modem
> flag
> >> signals, so that you do not start transmitting data until you see that
> the
> >> control signal has changed state.
> >
> >That's an idea worth examining. However it'll slow downloading with a JDM
> >style programmer to a crawl as supposedly these flags update on the order
> >of milliseconds.
>
> Well I was figuring it only needed to be checked at the beginning of a
> programming run. Turn on Vpp, check it is on, and then hose out the data in
> the manner you suggest. Surely you do not check Vpp with every byte?

Sorry. I thought you were thinking of using feedback to sync up TX with the
modem control signal for JDM style programming. This is an excellent idea for
switching Vpp.

BAJ

2006\02\03@025102 by Chen Xiao Fan

face
flavicon
face

> From: piclist-bouncesSTOPspamspamspam_OUTmit.edu
> [spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu] On Behalf Of Olin Lathrop
>
> So how about a 16F648A, which is actually cheaper than a 16F84?  
> The EasyProg (http://www.embedinc.com/easyprog) isn't the
> absolute simplest circuit because robustness and flexibility
> were also a concerns, but it's not real complicated either.  
> It would be easy to pare down the EasyProg circuit if you didn't
> care about variable Vdd and didn't try  to accommodate
> multiple target footprints in the ZIF socket.  If you do
> that, you can even start with the EasyProg firmware and strip some
> things out.  Many of the protocol commands are now optional that
> weren't when the EasyProg was designed, so the existing host software
> will just work as long as the firmware adheres to any of the published
> protocol spec versions.  You could even program dsPICs with it.

Actually this is an interesting idea --> a cost-down
"Cheap-n-EasyProg". ;-)

It may still be more complicated than Wisp628A but porting
of the EasyProg firmware might be easier than EasyISP. The
advantage of using EasyProg firmware will be the support of
dsPICs and base line PICs which Wisp628A does not support now.


Regards,
Xiaofan

2006\02\03@074709 by Byron A Jeff

face picon face
On Mon, Jan 30, 2006 at 12:14:44PM -0800, William Chops Westfield wrote:
> > Again, the point is to not require any programming software,
> >
> So, does this reduce to a request that flash PICs ship with a
> serial bootloader of some kind already installed in the flash?

That would have been nice. But it's a moot point.

It reduces to the fact that in the face of USB replacing traditional
ports, that there needs to be some way to wiggle signal lines on a
PC without requiring preprogrammed intelligence to do it. A USB to
serial cable is a compromise because it's readily available,
relatively inexpensive, and does have usages beyone connecting to
PIC projects.

My proposed code dumper simply adds to the possible spectrum. Many
folks will be happy to purchase a preassembled programmer and get on
with it. More power to them. Other's will go the route above and
purchase a preprogrammed PIC and assemble their own programmer. That's
fine too. But just because the I/O interface is shifting to USB doesn't
mean that those of us who wish to roll our own and not have a dependence
on outside vendors supplying a programming mechanism should be left out..

BAJ

2006\02\03@090626 by Gerhard Fiedler

picon face
Byron A Jeff wrote:

> My proposed code dumper simply adds to the possible spectrum. Many folks
> will be happy to purchase a preassembled programmer and get on with it.
> More power to them. Other's will go the route above and purchase a
> preprogrammed PIC and assemble their own programmer. That's fine too.
> But just because the I/O interface is shifting to USB doesn't mean that
> those of us who wish to roll our own and not have a dependence on
> outside vendors supplying a programming mechanism should be left out..

I'm not sure I get this yet... What's wrong with using the modem pins of a
serial port? Or is this what you are thinking of using?

Gerhard

2006\02\04@164057 by Byron A Jeff

face picon face
On Fri, Feb 03, 2006 at 12:04:32PM -0200, Gerhard Fiedler wrote:
> Byron A Jeff wrote:
>
> > My proposed code dumper simply adds to the possible spectrum. Many folks
> > will be happy to purchase a preassembled programmer and get on with it.
> > More power to them. Other's will go the route above and purchase a
> > preprogrammed PIC and assemble their own programmer. That's fine too.
> > But just because the I/O interface is shifting to USB doesn't mean that
> > those of us who wish to roll our own and not have a dependence on
> > outside vendors supplying a programming mechanism should be left out..
>
> I'm not sure I get this yet... What's wrong with using the modem pins of a
> serial port? Or is this what you are thinking of using?

Most of the reports that I have read have indicated that the modem pins
of a USB to serial converter cannot be controlled with the same precision
as a traditional serial port. The only interaction that is guranteed to
work with USB/serial converters are TX/RX interactions. So a bit wiggler
that utilizes this mode will work in all circumstances.

BAJ

2006\02\04@205030 by Gerhard Fiedler

picon face
Byron A Jeff wrote:

>> I'm not sure I get this yet... What's wrong with using the modem pins of
>> a serial port? Or is this what you are thinking of using?
>
> Most of the reports that I have read have indicated that the modem pins
> of a USB to serial converter cannot be controlled with the same
> precision as a traditional serial port.

That's also my understanding.

But I thought that this programmer's main use is to bootstrap a "real"
solution (that is, program a chip for a better programmer or program a
bootloader), so speed would not matter, and slowly wiggling the modem
signals is possible. (I'm no programming expert, but the programming specs
I've seen so far didn't list maximum times, only minimum times.) So the
only addition to a programmer that uses a traditional serial port would be
a (maybe configurable) timing control that slows the process down.

This might be easier to implement, more straightforward and possibly safer
(in terms of the programming success).

Gerhard

2006\02\04@232816 by Byron A Jeff

face picon face
On Sat, Feb 04, 2006 at 11:50:09PM -0200, Gerhard Fiedler wrote:
> Byron A Jeff wrote:
>
> >> I'm not sure I get this yet... What's wrong with using the modem pins of
> >> a serial port? Or is this what you are thinking of using?
> >
> > Most of the reports that I have read have indicated that the modem pins
> > of a USB to serial converter cannot be controlled with the same
> > precision as a traditional serial port.
>
> That's also my understanding.
>
> But I thought that this programmer's main use is to bootstrap a "real"
> solution (that is, program a chip for a better programmer or program a
> bootloader), so speed would not matter, and slowly wiggling the modem
> signals is possible. (I'm no programming expert, but the programming specs
> I've seen so far didn't list maximum times, only minimum times.) So the
> only addition to a programmer that uses a traditional serial port would be
> a (maybe configurable) timing control that slows the process down.

Or you could add feedback via one of the input modem control pins.

> This might be easier to implement, more straightforward and possibly safer
> (in terms of the programming success).

I personally think that wiring up a couple of 555s with a transistor and
a couple of discrete parts isn't too terribly difficult to put together.
The only think that I've found difficult so far is the RX feedback. But
for code dumping it really isn't even necessary.

BAJ

2006\02\05@033625 by William Chops Westfield

face picon face

On Feb 4, 2006, at 1:40 PM, Byron A Jeff wrote:
> Most of the reports that I have read have indicated that the
> modem pins of a USB to serial converter cannot be controlled
> with the same precision as a traditional serial port.

It's worse than that.  With modern (preemptive, multitasking)
operating systems, it's becoming difficult to precisely control
the bits of a serial or parallel port even if you have native
hardware.  We need something like a stream-based semi-realtime
bit-wiggling protocol, and then it could be run over serial,
USB, IRDA, Bluetooth, zigbee, or ... anything.  Unfortunately,
I'm not sure that anything short of some sort of code interpreter
on the destination would do the trick.  (Of course, since such
an interpreter has been shown to fit in a 16C54, maybe we should
juts byte the bullet and write a spec for such code...)

BillW

2006\02\05@135915 by David VanHorn

picon face
So do it at a higher level.  Send a hex file to a chip on the other side of
the USB interface, and let it do the pin wiggling, reporting back success or
failure as appropriate.

2006\02\05@201528 by Byron A Jeff

face picon face
On Sun, Feb 05, 2006 at 01:59:15PM -0500, David VanHorn wrote:
> So do it at a higher level.  Send a hex file to a chip on the other side of
> the USB interface, and let it do the pin wiggling, reporting back success or
> failure as appropriate.

Chicken and egg. That's what this is all about. What chip is inexpensive,
easy to obtain, simple to wire, and most importantly does not require yet another
programmer in order to program it?

I have 18F2550s sitting on my shelf. They would fit the bill fine. But how do
I program them to be a programmer without in fact buying yet another programmer?

Parallel simply did not require any true smarts on the target end. It was
a hacker's dream. Serial required more, but true serial ports did have
the ability to control a couple of modem control pins for input and output.

USB only for slow interfaces is an eventuality. It's too complex to build
something without innate intelligence in it.

As I said before the USB/serial (or possibly USB/parallel) cables represent
compromises as they are easily obtainable and have more than one purpose.

So the job becomes how to use such cables as interfaces. However, they do not
have the same level of accessibility as the native ports they replace.

I believe that it's a problem worth figuring out.

BAJ

2006\02\05@201721 by Byron A Jeff

face picon face
On Sun, Feb 05, 2006 at 12:36:22AM -0800, William Chops Westfield wrote:
>
> On Feb 4, 2006, at 1:40 PM, Byron A Jeff wrote:
> > Most of the reports that I have read have indicated that the
> > modem pins of a USB to serial converter cannot be controlled
> > with the same precision as a traditional serial port.
>
> It's worse than that.  With modern (preemptive, multitasking)
> operating systems, it's becoming difficult to precisely control
> the bits of a serial or parallel port even if you have native
> hardware.

All true. That's why I've reduced the problem to TX and RX only.
They at least can be trusted to behave.

>  We need something like a stream-based semi-realtime
> bit-wiggling protocol, and then it could be run over serial,
> USB, IRDA, Bluetooth, zigbee, or ... anything.  Unfortunately,
> I'm not sure that anything short of some sort of code interpreter
> on the destination would do the trick.  (Of course, since such
> an interpreter has been shown to fit in a 16C54, maybe we should
> juts byte the bullet and write a spec for such code...)

Possibly. However the chicken and egg to get such code into such
a chip (or set of chips) without having one first still exists.

BAJ

2006\02\05@204842 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: KILLspampiclist-bouncesspamBeGonespammit.edu
> [EraseMEpiclist-bouncesspamEraseMEmit.edu] On Behalf Of Byron A Jeff
> Sent: Monday, February 06, 2006 9:15 AM
>
> On Sun, Feb 05, 2006 at 01:59:15PM -0500, David VanHorn wrote:
>> So do it at a higher level.  Send a hex file to a chip on
>> the other side of the USB interface, and let it do the pin
>> wiggling, reporting back success or failure as appropriate.

I believe GTP-USB (with WinPIC800) is doing this since WinPIC800
support simple serial Port based JDM as well using the same
host software. It is using the 18F2550 as the USB interface and
not those common USB-to-serial chips. I am not 100% sure though
since I have not tried it and both the firmware and the
host software are closed source.

{Quote hidden}

I believe this is an interesting problem to figure out as
well. I think USB-to-serial converter will be more
common and more useful solution than USB-to-parallel
converter. I agree with you it is worth to investigate
the possibility to produce a reasonably simple programmer
based on USB-to-serial converter and it needs only to support
popular PICs like 16F88/16F876A/18F2520/18F2550 to be
useful to hobbyists. And a bootloader solution is not bad
as well for 16F88/16F876A/18F2520/18F2550. In fact I
like the bootloader function of PICkit 2 very much.

Still I think the chicken-and-egg problem is not as important
as you might think. Anyway, one needs to invest some time and
money to get into the PIC world. Programmer is only a
small part of the total investment. To me a multimeter and
an oscilloscope are much more essential than a programmer.
Guess I am a bit biased since I am an electronics engineer.


Regards,
Xiaofan

2006\02\05@213038 by kravnus wolf

picon face
A good programmer is important especially when one
spends so much time with MCU. Yes a GOOD multimeter
and oscilloscope are important.

John

{Quote hidden}

> --

2006\02\06@105230 by Byron A Jeff

face picon face
On Mon, Feb 06, 2006 at 09:48:40AM +0800, Chen Xiao Fan wrote:
>
> > -----Original Message-----
> > From: @spam@piclist-bounces@spam@spamspam_OUTmit.edu
> > [spamBeGonepiclist-bouncesspamKILLspammit.edu] On Behalf Of Byron A Jeff
> > Sent: Monday, February 06, 2006 9:15 AM
> >
> > On Sun, Feb 05, 2006 at 01:59:15PM -0500, David VanHorn wrote:
> >> So do it at a higher level.  Send a hex file to a chip on
> >> the other side of the USB interface, and let it do the pin
> >> wiggling, reporting back success or failure as appropriate.
>
> I believe GTP-USB (with WinPIC800) is doing this since WinPIC800
> support simple serial Port based JDM as well using the same
> host software. It is using the 18F2550 as the USB interface and
> not those common USB-to-serial chips. I am not 100% sure though
> since I have not tried it and both the firmware and the
> host software are closed source.

Well having closed source is not too helpful.

{Quote hidden}

As do I.

> I agree with you it is worth to investigate
> the possibility to produce a reasonably simple programmer
> based on USB-to-serial converter and it needs only to support
> popular PICs like 16F88/16F876A/18F2520/18F2550 to be
> useful to hobbyists.

Well once the hardware interface is in place it can theoretically
program any flash based PIC.

> And a bootloader solution is not bad
> as well for 16F88/16F876A/18F2520/18F2550.

Bingo. And that's the primary purpose I envision. As a bootloader
user, I find the utility of a traditional programmer is greatly
diminished. I am aware that it limits my chip selection and
in particular locks me out of an ICD style debugging interface.
But I've personally had good success using bootloaders with a
serial debugging backchannel to complete projects.

I also envision that when I delve into USB stuff, that having
that debugging backchannel that is separate serial debugging
interface separate from the USB, which the target is virtually
guaranteed to use, will be important.

So to me a programmer is little more than an ad hoc code dumper.

However, that USB to serial interface will retain its value
beyond simply serving as an interface for the ad hoc code dumper.

> In fact I like the bootloader function of PICkit 2 very much.
>
> Still I think the chicken-and-egg problem is not as important
> as you might think. Anyway, one needs to invest some time and
> money to get into the PIC world. Programmer is only a
> small part of the total investment. To me a multimeter and
> an oscilloscope are much more essential than a programmer.
> Guess I am a bit biased since I am an electronics engineer.

I came in from the software side. Most of my hardware debugging
is done with a logic probe and a multimeter. I rarely break out
the Oscope.

The chicken and egg problem is critical when one thinks that the
programmer function is redundant. I received a PS+ when I attended
a local Atlanta seminar several years ago. I used the PS+ for awhile
then put it away. The next time I wanted to do PIC stuff, I first
had a hard time locating the programmer, then when I finally located
it, it didn't work. I ended up scratch building a simple Tait style
programmer and loading WLoader into a 16F877. Development was a
breeze. I also realized that the programmer was ad hoc.

We all have different world views. What's important or not to each
of us is colored by experiences such as the one I outlined above.

Over the years I've had many users successfully utilize the Trivial
programmer in its various forms. It served a need for each of my
users. I'm simply extending the DIY development model that has
already been established. It's certainly not for everyone. However,
I feel that it's a niche that still needs to be filled even as we
move to PC interfaces that are so complex that no hobby user has
any hope of interfacing to it with simple hardware.

BAJ

2006\02\06@110245 by Byron A Jeff
face picon face
On Sun, Feb 05, 2006 at 06:30:37PM -0800, kravnus wolf wrote:
> A good programmer is important especially when one
> spends so much time with MCU. Yes a GOOD multimeter
> and oscilloscope are important.

It all depends on your POV. As a bootloader user, programmers
are completely out of my development cycle. My target is
connected directly to the PC with no intervening programmer.
So being the easiest to construct is the most important aspect
for a programmer.

My trivial programmer can be constructed in a breadboard,
can download bootloaders to target chips, and be torn down
all in less than an hour. From them on the target chips with
bootloaders on them can be programmed independent from a
programmer for the rest of their lifetime. RS-232 interfaces
such as Wouter's El-cheapo interface are small and simple
enough to be wired directly onto the target. Or a dongle can
be constructed if necessary.

The last true programmer I used was a PS+ over 10 years ago.
I hated the process.

BAJ
{Quote hidden}

2006\02\06@113643 by Alan B. Pearce

face picon face
>As a bootloader user, I find the utility of a traditional
>programmer is greatly diminished. I am aware that it
>limits my chip selection and in particular locks me out
>of an ICD style debugging interface.

I suspect that depends on how much work you are prepared to put into having
a bootloader/debugger. The ICD has a block of code in the chip to do the
debug interface, so adding that facility to a bootloader is really a matter
of perseverance.

2006\02\06@195413 by Chen Xiao Fan

face
flavicon
face

> From: .....piclist-bouncesspam_OUTspammit.edu
> [TakeThisOuTpiclist-bounces.....spamTakeThisOuTmit.edu] On Behalf Of Byron A Jeff
> Sent: Monday, February 06, 2006 11:52 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] [gnupic] noob's 1st ques
>
> Over the years I've had many users successfully utilize the Trivial
> programmer in its various forms. It served a need for each of my
> users. I'm simply extending the DIY development model that has
> already been established. It's certainly not for everyone. However,
> I feel that it's a niche that still needs to be filled even as we
> move to PC interfaces that are so complex that no hobby user has
> any hope of interfacing to it with simple hardware.
>

I can not agree with you on the last sentence. "Simple hardware" is
very subjective. Yes USB is not as easy as serial port. However,
USB interface chips have been around for years. Even the USB MCUs
like the USB PICs are getting more and more popular. I will not
say they are easy but they are within the reach of hobbyists.

And actually USB makes the hardware simpler in quite some cases
because it provides the power. The firmware can be more difficult
though. The host software can be more difficult. Still it is
within the reach of hobbyists.


Regards,
Xiaofan

2006\02\06@212854 by Byron A Jeff

face picon face
On Tue, Feb 07, 2006 at 08:54:10AM +0800, Chen Xiao Fan wrote:
>
> > From: TakeThisOuTpiclist-bouncesKILLspamspamspammit.edu
> > [.....piclist-bouncesspamRemoveMEmit.edu] On Behalf Of Byron A Jeff
> > Sent: Monday, February 06, 2006 11:52 PM
> > To: Microcontroller discussion list - Public.
> > Subject: Re: [PIC] [gnupic] noob's 1st ques
> >
> > Over the years I've had many users successfully utilize the Trivial
> > programmer in its various forms. It served a need for each of my
> > users. I'm simply extending the DIY development model that has
> > already been established. It's certainly not for everyone. However,
> > I feel that it's a niche that still needs to be filled even as we
> > move to PC interfaces that are so complex that no hobby user has
> > any hope of interfacing to it with simple hardware.
> >

I forgot an adjective: simple commodity hardware

> I can not agree with you on the last sentence. "Simple hardware" is
> very subjective. Yes USB is not as easy as serial port. However,
> USB interface chips have been around for years. Even the USB MCUs
> like the USB PICs are getting more and more popular. I will not
> say they are easy but they are within the reach of hobbyists.

The USB MCU's generally have the chicken/egg problem. Do you know of
any commodity USB MCUs that are bootloadable via USB out the box?

It's not really a foreign concept. The 68HC11 implemented a bootstrap
mode. Here's an app note describing it:

e-http://www.motorola.com/files/microcontrollers/doc/app_note/AN1060.pdf

Fundamentally it was a blank chip with a bootloader installed.

> And actually USB makes the hardware simpler in quite some cases
> because it provides the power. The firmware can be more difficult
> though. The host software can be more difficult. Still it is
> within the reach of hobbyists.

But it cannot bootstrap itself. So in order to use it you have to
get a minimally used programmer if you develop via bootloaders or
you have to get a preprogrammed chip with at least some minimal
bootloader in order to use it.

I know this isn't a big deal to most of you. But remember that the
original OP of this thread was going to have to multiply this action
with between 20 to 25 students. The bootloader angle was halted
because of the presumption that when the student needed another
project, that they would have to purchase a programmer anyway.

At the end of the day parallel and serial ports are bootstrappable
with easily obtainable, low cost hardware. USB components are not
commodity. Take the Dontronics DLP USB modules page for example:

http://www.dontronics.com/dlp.html

$33 USD + shipping to get a USB interfacable module.

One last point: Bootstrapping with a serial interface means that real
serial ports can also be used. Lots of JDMs have problems with serial ports
with junky (0/5V) outputs. A code dumping board that is designed to work
in that voltage range would also be a boon to those who have real serial
ports too.

BAJ

2006\02\06@224229 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesspamspamBeGonemit.edu
> [spamBeGonepiclist-bounces@spam@spamspam_OUTmit.edu] On Behalf Of Byron A Jeff
>
> It's not really a foreign concept. The 68HC11 implemented a
> bootstrap mode. Here's an app note describing it:
>
>Fundamentally it was a blank chip with a bootloader installed.

If you do not want to talk about PIC, yes all the Freescale
68HC908 flash parts have a monitor ROM inside. Even the 8-pin  
MC68HC908QT1/2/4 have the monitor ROM inside. By the way,
68HC05/68HC11/68HC16 are no longer promoted by Freescale.
Freescale promotes more the 68HC908/HCS08 and 68HC912/HCS12 family.

I need to check out the Freescale USB part since I am not so familiar
with the HC908 parts and I do not like its high active current
consumption compared to PICs and AVRs.

However the design of PIC MCU will not allow Microchip to install
a bootloader inside without occupying programming space. Moreover
many customers will not need the bootloader. And there are many
bootloaders out there.

Regards,
Xiaofan

2006\02\06@234739 by Byron A Jeff

face picon face
On Tue, Feb 07, 2006 at 11:42:27AM +0800, Chen Xiao Fan wrote:
>
>
> > -----Original Message-----
> > From: TakeThisOuTpiclist-bouncesspamspammit.edu
> > [piclist-bouncesEraseMEspammit.edu] On Behalf Of Byron A Jeff
> >
> > It's not really a foreign concept. The 68HC11 implemented a
> > bootstrap mode. Here's an app note describing it:
> >
> >Fundamentally it was a blank chip with a bootloader installed.
>
> If you do not want to talk about PIC, yes all the Freescale
> 68HC908 flash parts have a monitor ROM inside. Even the 8-pin  
> MC68HC908QT1/2/4 have the monitor ROM inside. By the way,
> 68HC05/68HC11/68HC16 are no longer promoted by Freescale.
> Freescale promotes more the 68HC908/HCS08 and 68HC912/HCS12 family.

The point still stands that a factory loaded bootloader could in
fact have utility.

> I need to check out the Freescale USB part since I am not so familiar
> with the HC908 parts and I do not like its high active current
> consumption compared to PICs and AVRs.
>
> However the design of PIC MCU will not allow Microchip to install
> a bootloader inside without occupying programming space.

That's a tradeoff.

> Moreover many customers will not need the bootloader.

Doesn't matter. Under the presumption that someone doesn't need a
bootloader, it'll be gone the first time the chip is erased.

Of course the point is moot as Mchips doesn't put bootloaders into
any of their line.

> And there are many bootloaders out there.

Chicken and egg. If one doesn't like the default bootloader they can
use it to load up a bootloader that they did like.

I'm thinking this thread is wrung out. I plan to work on my serial
port code dump and bootloader firmware. Then anyone interested in
using it will have it available.

BAJ

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

face picon face
>However the design of PIC MCU will not allow Microchip to
>install a bootloader inside without occupying programming space.

I do not think that is correct. IIRC all processors are capable of having
the program counter go higher than the highest memory location (i.e. there
is at least one extra bit in the PC than required for the Flash memory
supplied). It surprised me to find that the 10F chips are done like this.

>Moreover many customers will not need the bootloader.
>And there are many bootloaders out there.

Well I suspect that if a standard bootloader was available in every chip off
the shelf, then more people than currently do would use it. The reason there
are so many bootloaders available is there is no standard.

The Freescale bootloader seems to have made a reasonable job of occupying
only one pin and still give bi-directional communication, along with debug
capabilities. But it also has other things tightly integrated to the chip,
such as what cannot be used in its facilities when the chip has the Flash
Memory protected. I have looked at only the HCS12 family, but it appears to
severely limit the instructions available when chip protection is set.

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