gnupic: Thread: Question for you all

Hi all, investigating more on my pic problems where
the only combination I ever got to work was a ludipio
programmer (too simple) with PonyProg (many device
types but a limited device list for pic devices) I sat
down and got to think, what was it? why is PonyProg
the only program that ever worked for me in all the
programs I've tested both Linux and Windows to burn
either with the El Cheapo, Byron's TLVP or Ludipio
Using 16C84 or a 16F627-04 chip I bought why was
PonyProg the only one to work (cheers to the PonyProg
guys you rock) well I revised everythign and the only
diference between PonyProg and the rest is that Pony
tested my system's response to set an appropiate delay
during programming, and compared with all the failed
attempts to program with prog84, picprg and ic-prog
Pony's programmign and reading is considerably slower
than the failed attempts, and it works... so I got to
think it might be timing... looking around I see that
with some work (maybe a lot) I can modify prog84's
dosutil to perform loop calibration under linux, but
then I sat to think, I've had success with a 16C84 and
it works well, and in the future I want to do a lot of
things as a hobbyst (i'm very ambicious you see :)
like programming myself a few open source boot roms
for network cards, workign with 24CXXs in a few
projects etc etc so why don't I use this Ludipio and
this 16C84 as a stepping stone to go forward? since I
can't currently buy dollars or any other foreign
currency (there is a locally emplaced exchange embargo
in my country right now) buying a preprogramed
16F628-20 for makign myself a Wisp628 or buying the
kit for a PonyProg hardwarer is out of the question, I
have to do this myself... I tried (shortly, if I try
for more time I am sure I will suceed) to get JAL to
run to recompile the Wisp628 firmware just swapping
the f628-20 include for a f628-4i or the 16F628-4
includes but I have't configure JAL enought to be able
to compile and I failed (I would've burned this to the
16F627 simulating it was a 16F84 with PonyProg) but
anyhow I won't go on this anymore, for one side I
thinkg the Wisp628 is a good device if I was to use
the firmware I would preffer to be able to buy the
programmed 628 to help the guy with some money if even
a little... also I want to make this expansible
because I have a few leftover multiplexers from comp
architecture class so I want to use them trigged by
the pic to reduce the number of adapters and boards
and sockets needed in my own made programmer :) so I
preffer to code as a learnign process the firmware
myself, and I've decided to do this in C for it has
enough high level and at the same time simplicity as
to make the effort faster and easier to maintain.

Btw I haven't told you why I want to make a pic based
programmer.... two simple reasons.. 1) Using the 16C84
as a buffer and programmer for other devices I can
have timing on pic and the PC's port and cpu speed
won't caus eme more headaches tryign to program
diferent devices and calibrating.... and 2) using the
16C84 as a stepping stone (with a max232 I have lyign
around) I can communicate with the pic and target
device using only Tx and Rx of the serial port...
carrying the programmer around (I plan to do it as
small as I can) this means I can use host machines
(like palm pilots or even dumb temrinals) to program
whethever I have user acces only and wherever the
system (hardware or software) does supports hardware
flow control or not :)

So why I write you after this looong essay, to make 2
questions.

1) Do you think my approach is allright? is it prone
to success? :)

2) I intend to do this on C, it's much easier, so my
question is, I've overseen slightly (very slightly)
both C2C and SDCC for the pic... which one would you
choose? and why?

Any advice you want to give me is welcome. and thank
you all a lot.

Lars.

=====
/|\               /    \
A dragon         ((    ))
a day         /\  \\/\//  /\
lights your  ///\ (o<>o) /\\\
way         /////\ \}{/ /\\\\\
/|\        ////ooO\(oo)/Ooo\\\\
---------------VVV------VVV---------------

On Thu, 1 May 2003, Lars Goldschlager wrote:

[big snip]

>Btw I haven't told you why I want to make a pic based
>programmer.... two simple reasons.. 1) Using the 16C84
>as a buffer and programmer for other devices I can
>have timing on pic and the PC's port and cpu speed
>won't caus eme more headaches tryign to program
>diferent devices and calibrating.... and 2) using the
>16C84 as a stepping stone (with a max232 I have lyign
>around) I can communicate with the pic and target
>device using only Tx and Rx of the serial port...
>carrying the programmer around (I plan to do it as
>small as I can) this means I can use host machines
>(like palm pilots or even dumb temrinals) to program
>whethever I have user acces only and wherever the
>system (hardware or software) does supports hardware
>flow control or not :)

I had other problems that led me to do something similar recently. I made
a PIC programmer based on a PIC16F84 and wrote the code in C (for the CCS
PIC C compiler), but I haven't released it because there are bugs and I
was thinking I'd probably ditch it for the Wisp628.

What I made does not use RTS/CTS or XON/XOFF flow control, so to insure
everything works, it uses a protocol implemented by a rather messy POSIX
compliant C program that is similar to the one used by my latest
bootloader.  It cannot be used with a simple terminal program, but the
advantage is that less data goes over the serial line and more processing
can occur on the PC rather than the PIC. Flow control is done within the
protocol.  Since the C program should compile on a great many platforms, I
wasn't worried about support. I've compiled it on Linux, and would have
compiled it on Windows, but the Windows system botched itself first.

I tried to make so that it could be extended to support multiple devices,
but I only implemented midrange PIC flash ROM programming, and that
implementation cannot properly erase all parts. It has only been tested
with a PIC16F84 and a PIC16F877A.  Reading the exiting code only works
before writting code, but it was intented to work after writting code,
too.

Anyway, if this sounds like something useful and you don't want to start 
from nothing, I can send you the code and provide some help in figuring it 
out.

-- 
Jeff Jackowski
        http://ro.com/~jeffj/

On Thu, May 01, 2003 at 01:42:47PM -0700, Lars Goldschlager enlightened us thusly
> 
> Btw I haven't told you why I want to make a pic based
> programmer.... two simple reasons.. 1) Using the 16C84
> as a buffer and programmer for other devices I can
> have timing on pic and the PC's port and cpu speed
> won't caus eme more headaches tryign to program
> diferent devices and calibrating.... and 2) using the
> 16C84 as a stepping stone (with a max232 I have lyign
> around) I can communicate with the pic and target
> device using only Tx and Rx of the serial port...
> carrying the programmer around (I plan to do it as
> small as I can) this means I can use host machines
> (like palm pilots or even dumb temrinals) to program
> whethever I have user acces only and wherever the
> system (hardware or software) does supports hardware
> flow control or not :)
>

I'm sitting here wondering. You can buy a Picstart, or any programmer
_known_ to work with certain software. I'm using picp with that. I never
actually figured out mplab's windows stuff - I never had to. 

In passing, I would feel you may have given up rather quickly on some of
the programs out there. If you had come here with your problems, I am
reasonably sure they would have been sorted

If you want experience and training, rock on. If you want results, why
reinvent the wheel?

-- 

	With best Regards,


	Declan Moriarty.