Subject:
Re: [gnupic] k150 USB Programmer and Rick Altherr's pp
From:
Micah Carrick ####@####.####
Date:
23 Aug 2005 18:13:25 +0100
Message-Id: <430B592F.4030308@micahcarrick.com>
Wow, you're always so quick to respond. Thanks :)
I believe I have seen some other references to users who have used your
code in Linux and I'm curious to hear there struggles-- if any.
Okay, well I'm going to continue to play around this code when I get a
chance. Currently gotta do some coding to pay the bills-- but I will
work on it and let you know what I come up with-- if anything :) As
I've said before, I'm new to Linux programming and C so I'm taking it
relatively slowly. But I'm definetely interested in getting this
working for Linux and maybe build a simple GUI for it in GTK later. I
really hate having to reboot in to windows to program the chip.
1. Do you know which header include is missing?
2. Let me see if I understand (I have the protocol, just want to make sure)
- Board is powered up, sends 'B' and then board type (in my case, 3 for
k150)
- At this point, it is NOT in command mode and thus a command 1 won't do
anthing
- I could send a 'P' which should send back a 'P' indicating it's ready
to recieve a command
- Then it can go through the commands as needed.
Am I understanding this protocol correctly?
Micah
Rick Altherr wrote:
> 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: ####@####.####
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>
>
