Re: k150 USB Programmer and Rick Altherr's pp

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
> [email protected]
>
> "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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
>