Re: [Uisp-dev] Bug in uisp?

[Joakim Arfvidsson]

Yeah I see it's on the scale of seconds... won't be about that then.

This is the output with all occurrences or just the one with set_device 
(same output) having the last argument set to 2: (I also tried to add 
the third argument at some places where only two were used, to no 
visible effect)


Transmit: { V [56] }
Receive: { 2 [32] }
Receive: { 3 [33] }
Transmit: { v [76] }
Receive: { a [61] }
Receive: { a [61] }
Programmer Information:
  Software Version: 2.3, Hardware Version: a.a
Address Auto Increment Optimization Enabled
Transmit: { t [74] }
Receive: { U [55] }
Receive: { V [56] }
Receive: { . [13] }
Receive: {   [20] }
Receive: { ( [28] }
Receive: { 8 [38] }
Receive: { H [48] }
Receive: { L [4c] }
Receive: { 4 [34] }
Receive: { 0 [30] }
Receive: { l [6c] }
Receive: { h [68] }
Receive: { e [65] }
Receive: { ` [60] }
Receive: { d [64] }
Receive: { A [41] }
Receive: { B [42] }
Receive: { . [00] }

Trying with: AT90S1200
Transmit: { T [54] . [13] }
Receive: { . [0d] }
Programmer is not responding.

This is the output every time it "works", even the first time. So it's 
not usable. A strange thing is that it doesn't fail completely after as 
few attempts as before (one). Now I can get as far as the dump below 
shows up to 10 times before it once receives a 3, and all the following 
times receives nothing at all...

It's a 2313 chip by the way. Setting chip selection hard instead of 
leaving it automatic has no significant effect.

Finally, after having seen the above a few times (or one):

Transmit: { V [56] }
Receive: { 3 [33] }
Programmer is not responding.

And then only this, every time:

Transmit: { V [56] }
Programmer is not responding.

My local stores don't even have USB-serial adapters...

Thanks,
Joakim Arfvidsson


On 2004-03-02, at 20.39, Jason Kyle wrote:

> It's fairly embedded into the code, isn't just a define but is quite 
> visible.
>
>
> Send data routine (Serial.C):
> int TSerial::Send(unsigned char* queue, int queue_size, int 
> rec_queue_size,
>                   int timeout)
>
> There is a timeout parameter and it's set according to the operation, 
> although it appears to be in seconds so my theory is probably not 
> valid.
>
> For a laugh, and maybe a result?, edit the file uisp/src/AvrAtmel.C 
> and -everywhere- you see something -like- Send(set_device, 2, 1)  
> change the *last* number to 1 or 2 more  i.e. Send(set_device, 2, 2)  
> then recompile and see what happens.
>
> Jason