gnupic: [gnupic] k150 USB Programmer and Rick Altherr's pp
Subject:
Re: [gnupic] k150 USB Programmer and Rick Altherr's pp
From:
Rick Altherr ####@####.####
Date:
23 Aug 2005 17:24:12 +0100
Message-Id: <B55C392D-2624-4CF1-ACBD-6525B25F9BD5@kc8apf.net>
See below.
--
Rick Altherr
####@####.####
"He said he hadn't had a byte in three days. I had a short, so I
split it with him."
-- Slashdot signature
On Aug 23, 2005, at 9:05 AM, Micah Carrick wrote:
> Hello,
>
> I posted a while back and Rick had helped me and I haven't been
> able to
> work on it again until now.
> First, I'd be curious to know how many people out there are using the
> Kitsrus k150 USB PIC programmer
> successfully in Linux? I'm using Fedora Core 4 and have not been
> successful.
>
Like I've said before, I've never been successful under linux. I
haven't had time to play with it recently, but I would like to figure
out what is wrong.
> If anybody can offer some suggestions for troubleshooting my problem?
> I'd be very greatful
> and gladly document all my findings online to help others with similar
> problems should I be able to
> get it resolved. Here's what I've done:
>
> 1. Loaded the FTDI module.
> 2. Upgraded and verified the firmware of the k150 to "P018"
> 3. Compiled and tinkered with pp
>
>
> I'm still unable to work the programming software. I'm continually
> getting the message:
> Error: failed to reset board
>
> which upon playing with the code, I've learned the following:
>
> 1. I noticed that after the first run of the program (until powering
> down the programmer) and only
> AFTER the first run, the programmer starts up with 'B' and 3 ready
> to be
> read (just as the
> software protocol says), but I don't understand why it happens only
> after the first time running
> the program. This seems to be simple "cleared" in pp.c with the
> following:
>
> 221: // For some reason there is always a left-over byte
> 222: read(serialFd,buffer,255);
>
The B and 3 are sent by the programmer when it is first turned on.
This is normal. I should be doing more to detect if this is true and
then avoid the next check, but this seems to work according to the
protocol spec.
> 2. Right after that, a call is made to the function programmer_reset()
> which is in programmer.c where
> the command 1 is sent and then 'Q' (ascii) is expected back,
> however, in
> my case the read() function
> is returning 0 bytes. I've been playing around and this is true when I
> send just about any command.
> The read operation always returns 0 bytes except for when the program
> firsts starts (as I mentioned
> above) where the read function returns 2 bytes, the 'B' (ascii) and 3
> indicating a K150.
>
> 224: // Attempt to send a "reset"
> 225: if (programmer_reset(serialFd) != 0) {
> 226: printf("Error: failed to reset board\n");
> 227: return EX_SOFTWARE;
> 228: }
>
Command 1 is a reset command. If the programmer is in command mode,
it moves it out of command mode. If the programmer is in the "pre-
command" mode, then it just stays there. I'll have to read the
protocol spec again, but I'm pretty sure that this is correct.
> 3. And the only other clues I have now is during the make I get
> several
> errors similar to the two below
> only I'm not sure what, if any, significance these have as they are
> just
> warnings:
>
> pp.c:78: warning: incompatible implicit declaration of built-in
> function
> ‘strcpy’
> pp.c:304: warning: pointer targets in passing argument 2 of
> ‘programmer_read_config’ differ in signedness
>
These are both fairly benign. The first is because I forgot to
include a header for strcpy. The second is because I pass in a char
* when it expects a unsigned char *. This shouldn't hurt anything,
but I try to make warning free code.
>
> And if you've gotten this far, thanks for taking the time to read my
> boring old email :)
>
> - Micah Carrick
> http://www.micahcarrick.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
