On Fri, Jun 11, 2004 at 10:10:15AM +0100, Antonio Sergio Sena wrote:
> > > Im using the Tiny Bootloader for a long time, in applications where i
> need
> > > the USART to talk with other external devices.
> > > At Reset is waits for the Bootloader, if not or if it ended, the USART
> is
> > > fully configurable to my needs.
>
> > But the question is how do you wire it so that you can bootload and use it
> in
> > the application? For example if your PIC is interacting with an external
> modem
> > then the UART needs to be connected to the modem and to the PC for
> bootloading.
> > Do you use a switch?
>
>
> No, in most cases i just switch plugs. It may be time consuming, but so far
> hadnt have any problems.

I find that when I'm developing, the less hardware manipulations I have to do,
the more progress I make on the software side. So I work to get the hardware
configured, then I want to leave it alone while pulling the software together.

Just a personal preference I guess. Too many years programming desktop and
server hardware.

> Confess that i never had 1000 PICs to update at the same time, like Wouter
> has to do.

Then you'd be looking at something different of course.

>
> When using the USART for external equipment, for most of the tests i just
> use a terminal software to input data and get feedback.

But that requires bit banging a port right? So you actually do a double
cable switch then where for programming you plug the PIC USART into the PC
to run the bootloader, then to run the application you plug the USART into
the external equipment, and the PC serial port into a bit banged port on the
PIC? Just wondering.


>
> > Bootloaders that use unused resources for the loading port facilitates
> > development because both the loader and the UART can be connected at the
> same
> > time without interference. That's why I favor Wouter's loaders which picks
> > out of the way spots for the loader port. Even better, the loader port
> > (at least for Wloader) can double as a serial debug port independant of
> the
> > application.
>
> True! very true!  I may give it a try one i finish what im doing now.
>
> I particularly like the Debugging feature of it, its quite helpful. Specialy
> to avoid the ICE.

Well ICE definitely has its advantages. There's no other way to interact with
a debugging system running at full speed.

Be aware that your application has to implement the bit banged debugging port
via the Wloader interface pin. I simply set up timer2 with the bit rate
I'm interested in since it can be configured to raise a flag on a particular
count. You can see my dgbout routine near the bottom of my sunrise/sunset
outside light controller code here:

http://www.finitesite.com/d3jsys/clock.asm

It's barely 20 lines of code for the application. I never bothered to build
an input routine, though it wouldn't be too hard to do.

But in the scenario where you're cable switching above, in my setup the USART
is permanently connected to the application, and the Wloader port is
permanently connected to the PC serial port (during the development cycle of
course. Once the project is finished, the PC is completely disconnected.)

And it gets even better. Woj Zabolotny, who coded up an excellent Linux wloader
WISP protocol clone called linwload, actually coded up a mini terminal emulator
into the loader. So it's possible to load a new hex file via the bootloader,
fire up the new application, and then go into debugging mode in a single
command: linwload PROG newfile.hex GO TERM

As you can see this makes for an extremely efficient setup with no cable
switching and no applications switching either, with application debugging
available.

And that's why I'm so enamored with bootloaders.

Writing this discussion I realize that even when I do get around to
implementing ZPL for the 16F series that I'll still want to implement a
single pin bit banged serial debugging interface that shares the PC serial
port with the ZPL interface for the reasons outlined above.

An aborted thought: I really wish that Microchip would implement what someone
else pointed out a couple of days ago: since the MCLR function can be
turned off in nanowatt parts, why not add an NFET pulldown making MCLR an
open drain output. It shouldn't be too hard to do, right? Then while ZPL would
turn into three/quarterPL ;-) You can get the debugging interface only using
the RA5/MCLR pin. But it's wrong thinking because you can't have both the I/O
function and the MCLR function at the same time. So forget it.

Back to the point, I'll probably wire RA0 as a bit banged one pin serial
interface back the PC for the ZPL16F. Then you can get the same benefits as
outlined with linwload above.

BAJ
>
>
>
> Antonio Sergio Sena
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics