attiny10 with ftdi and bitbang

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

attiny10 with ftdi and bitbang

matthew venn
Hi all,
I've been working to reproduce work I found here:
http://irq5.wordpress.com/2010/07/15/programming-the-attiny10/

I'm using avrdude 5.11 on ubuntu10.04

I've added this to avrdude.conf:

programmer
  id    = "dasaftdi";
  desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
  type  = serbb;
  sck   = ~7;
  reset = ~1;
  miso  = ~8;
  mosi  = ~3;
;

The command I'm using is:
./bin/avrdude -p attiny10 -c dasaftdi -P /dev/ttyUSB0 -v -v -v -v

I've got to the stage where I can see the clock and mosi/miso lines going
(with a scope) but avrdude always times out.
Looking through the code (bitbang.c) and adding some debugging I found it's
in a loop waiting for something to happen:

tries = 0;
    do {
      rc = pgm->program_enable(pgm, p);
      if ((rc == 0)||(rc == -1))
        break;
      pgm->highpulsepin(pgm, pgm->pinno[p->retry_pulse/*PIN_AVR_SCK*/]);
      fprintf(stderr, "retry pulse\n");
      tries++;
    } while (tries < 65);

But I'm afraid I can't work it out. The comment above say's its waiting for
a response of 0x53 but I can't see that referenced in the code, the
attiny10 config or in Atmel's tpi pdf:
http://www.atmel.com/Images/doc8373.pdf

If I return 0 before this code then avrdude continues but never receives
anything back from the chip:

avrdude: Calibrating delay loop... calibrated to 306 cycles per us
doing MOSI-MISO link check
MOSI-MISO link present
avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0%
0.00sbitbang_cmd_tpi(): [ 72 ] [ 00 ]
bitbang_cmd_tpi(): [ F3 00 ] [ ]
bitbang_cmd_tpi(): [ 68 C0 ] [ ]
bitbang_cmd_tpi(): [ 69 3F ] [ ]
bitbang_cmd_tpi(): [ 24 ] [ 00 ]
bitbang_cmd_tpi(): [ 24 ] [ 00 ]
Reading | #################                                  | 33%
9.00sbitbang_cmd_tpi(): [ 24 ] [ 00 ]
Reading | ################################################## | 100% 10.45s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

However, the TPI ident tag is being read correct, and the MOSI-MISO link is
working.

I've also tried using -i with values from 1 to 100000.

I'm giving up for today, but if anyone can think of something to try next
I'd appreciate it!

Matt

--
Matthew Venn
mattvenn.net
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Matt,

Here's my command line (on my Mac):

avrdude -vv -p t10 -P /dev/tty.usbserial-A6007ul6 -c dasaftdi

And the working output should be:

...
bitbang_cmd_tpi(): [ 72 ] [ 00 ]
bitbang_cmd_tpi(): [ F3 00 ] [ ]
bitbang_cmd_tpi(): [ 68 C0 ] [ ]
bitbang_cmd_tpi(): [ 69 3F ] [ ]
bitbang_cmd_tpi(): [ 24 ] [ 1E ]
bitbang_cmd_tpi(): [ 24 ] [ 90 ]
Reading | #################                                  | 33% 0.40s
bitbang_cmd_tpi(): [ 24 ] [ 03 ]
Reading | #################################                  | 66% 0.47s
Reading | ################################################## | 100% 0.47s

avrdude: Device signature = 0x1e9003

The last 3 cmd_tpi should return the device signature bytes, which in
your case are all zeroes. The odd thing is, your tiny10 seems to be
correctly framing those zeroes. If the tiny10 had just not responded
all the way, you would see an error that says "stop bits not received
correctly".

If it's stuck in that loop, it's basically calling program_enable,
which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
to be set.

--
Regards,
Darell Tan


On Fri, Jun 29, 2012 at 11:22 PM, matthew venn <[hidden email]> wrote:

> Hi all,
> I've been working to reproduce work I found here:
> http://irq5.wordpress.com/2010/07/15/programming-the-attiny10/
>
> I'm using avrdude 5.11 on ubuntu10.04
>
> I've added this to avrdude.conf:
>
> programmer
>  id    = "dasaftdi";
>  desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
>  type  = serbb;
>  sck   = ~7;
>  reset = ~1;
>  miso  = ~8;
>  mosi  = ~3;
> ;
>
> The command I'm using is:
> ./bin/avrdude -p attiny10 -c dasaftdi -P /dev/ttyUSB0 -v -v -v -v
>
> I've got to the stage where I can see the clock and mosi/miso lines going
> (with a scope) but avrdude always times out.
> Looking through the code (bitbang.c) and adding some debugging I found it's
> in a loop waiting for something to happen:
>
> tries = 0;
>    do {
>      rc = pgm->program_enable(pgm, p);
>      if ((rc == 0)||(rc == -1))
>        break;
>      pgm->highpulsepin(pgm, pgm->pinno[p->retry_pulse/*PIN_AVR_SCK*/]);
>      fprintf(stderr, "retry pulse\n");
>      tries++;
>    } while (tries < 65);
>
> But I'm afraid I can't work it out. The comment above say's its waiting for
> a response of 0x53 but I can't see that referenced in the code, the
> attiny10 config or in Atmel's tpi pdf:
> http://www.atmel.com/Images/doc8373.pdf
>
> If I return 0 before this code then avrdude continues but never receives
> anything back from the chip:
>
> avrdude: Calibrating delay loop... calibrated to 306 cycles per us
> doing MOSI-MISO link check
> MOSI-MISO link present
> avrdude: AVR device initialized and ready to accept instructions
>
> Reading |                                                    | 0%
> 0.00sbitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C0 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 24 ] [ 00 ]
> bitbang_cmd_tpi(): [ 24 ] [ 00 ]
> Reading | #################                                  | 33%
> 9.00sbitbang_cmd_tpi(): [ 24 ] [ 00 ]
> Reading | ################################################## | 100% 10.45s
>
> avrdude: Device signature = 0x000000
> avrdude: Yikes!  Invalid device signature.
>         Double check connections and try again, or use -F to override
>         this check.
>
> However, the TPI ident tag is being read correct, and the MOSI-MISO link is
> working.
>
> I've also tried using -i with values from 1 to 100000.
>
> I'm giving up for today, but if anyone can think of something to try next
> I'd appreciate it!
>
> Matt
>
> --
> Matthew Venn
> mattvenn.net
> _______________________________________________
> avrdude-dev mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/avrdude-dev

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

matthew venn
Dan, thanks for this.

If it's stuck in that loop, it's basically calling program_enable,
> which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
> to be set.
>

Yes what I'm seeing is the program enable section (detailed in that Atmel
pdf) called 64 times before avrdude gives up.

So am I right in that the tiny10 is responding at some points? It's been
harder than usual to trace because all the comms happens on 1 wire. I'm
wondering if I could use some diodes on mosi and miso so I could scope
before they are merged.

Someone at the hackspace I'm at (Bristol) has an avrisp mk2 which can do
TPI. So I'll try that. I've had exactly the same thing with another
attiny10 so I think it must be my wiring or the software/pc side of things.

One really odd thing I noticed about avrdude and the dasa config was that
when I was testing the outputs of the ftdi cable to check that I was
getting clock etc, was that if I had

reset = 7
sck = 3

that would work (both lines generated pulses), but with

reset = 3
sck = 7

only one of them would then generate signals. I've written those from
memory so I'm not entirely sure which way round they are but it seemed like
a bug to me at the time and now I'm wondering if there is something similar
with mosi and miso. Except that the mosi miso link check tests OK...

Oh well, I'll get there in the end I imagine!
Thanks again,

Matt

--
Matthew Venn
mattvenn.net
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Matt,

Basically the reset line would only go down once, and will not be
released until the programming is done. The 2 other lines are the CLK
and DATA. Since the DATA line is only used by one party at a time, if
the tiny10 tried to transmit while avrdude was transmitting, it would
go into an error state and wait for a break. If you could probe the
lines with a logic analyzer, I'd be happy to take a look.

This problem of yours is quite a puzzle, especially if both tiny10s
responded the same way. If the tiny10 can properly frame the zeroes
and respond with the TPIIR correctly, it sounds like some protocol
error occurred somewhere in between.

Well if you have any further thoughts or do get it to work, I'd like
to hear about it.

--
Regards,
Darell Tan


On Sat, Jun 30, 2012 at 7:23 PM, matthew venn <[hidden email]> wrote:

> Dan, thanks for this.
>
>> If it's stuck in that loop, it's basically calling program_enable,
>> which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
>> to be set.
>
>
> Yes what I'm seeing is the program enable section (detailed in that Atmel
> pdf) called 64 times before avrdude gives up.
>
> So am I right in that the tiny10 is responding at some points? It's been
> harder than usual to trace because all the comms happens on 1 wire. I'm
> wondering if I could use some diodes on mosi and miso so I could scope
> before they are merged.
>
> Someone at the hackspace I'm at (Bristol) has an avrisp mk2 which can do
> TPI. So I'll try that. I've had exactly the same thing with another attiny10
> so I think it must be my wiring or the software/pc side of things.
>
> One really odd thing I noticed about avrdude and the dasa config was that
> when I was testing the outputs of the ftdi cable to check that I was getting
> clock etc, was that if I had
>
> reset = 7
> sck = 3
>
> that would work (both lines generated pulses), but with
>
> reset = 3
> sck = 7
>
> only one of them would then generate signals. I've written those from memory
> so I'm not entirely sure which way round they are but it seemed like a bug
> to me at the time and now I'm wondering if there is something similar with
> mosi and miso. Except that the mosi miso link check tests OK...
>
> Oh well, I'll get there in the end I imagine!
> Thanks again,
>
> Matt
>
> --
> Matthew Venn
> mattvenn.net

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

matthew venn
I finally got it working, but I've no idea how!! If anyone can give me some
ideas on why this works that would be great.

Here is the output of avrdude:

avrdude: AVR device initialized and ready to accept instructions
bitbang_cmd_tpi(): [ 72 ] [ 00 ]
bitbang_cmd_tpi(): [ F3 00 ] [ ]
bitbang_cmd_tpi(): [ 68 C0 ] [ ]
bitbang_cmd_tpi(): [ 69 3F ] [ ]
bitbang_cmd_tpi(): [ 20 ] [ 1E ]
bitbang_cmd_tpi(): [ 72 ] [ 00 ]
bitbang_cmd_tpi(): [ F3 00 ] [ ]
bitbang_cmd_tpi(): [ 68 C1 ] [ ]
bitbang_cmd_tpi(): [ 69 3F ] [ ]
bitbang_cmd_tpi(): [ 20 ] [ 90 ]
bitbang_cmd_tpi(): [ 72 ] [ 00 ]
bitbang_cmd_tpi(): [ F3 00 ] [ ]
bitbang_cmd_tpi(): [ 68 C2 ] [ ]
bitbang_cmd_tpi(): [ 69 3F ] [ ]
bitbang_cmd_tpi(): [ 20 ] [ 03 ]
avrdude: Device signature = 0x1e9003

with avrdude command:

./bin/avrdude -C /etc/avrdude.conf -p t10 -c dasaftdi -P /dev/ttyUSB0 -v -v
-v -v -q

And definition of dasaftdi:

programmer
  id    = "dasaftdi";
  desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
  type  = serbb;
  sck   = ~7; #green (rts)
  reset = ~2; #yellow (rx)
  mosi  = ~3; #orange (tx)
  miso  = ~8; #brown (cts)

The wiring from ftdi to attiny10 was the key part though:

black (gnd) -> 2 (gnd)
brown (cts) via a diode -> 1 (data)
orange (tx) via a 1k resistor -> 1 (data)
red (+5v) -> 5 (vcc)
black (gnd) -> 6 (reset)

The diode is important, without the programming fails with the previous
error of getting stuck in the program enable loop for 64 times.

The most confusing thing for me is that the diode has to allow current to
flow from the miso to the mosi pin. But MOSI stands for master out slave
in, so isn't this the wrong way round?

But hooray it's working!!!

Cheers,
Matt



On 30 June 2012 14:50, Darell Tan <[hidden email]> wrote:

> Hi Matt,
>
> Basically the reset line would only go down once, and will not be
> released until the programming is done. The 2 other lines are the CLK
> and DATA. Since the DATA line is only used by one party at a time, if
> the tiny10 tried to transmit while avrdude was transmitting, it would
> go into an error state and wait for a break. If you could probe the
> lines with a logic analyzer, I'd be happy to take a look.
>
> This problem of yours is quite a puzzle, especially if both tiny10s
> responded the same way. If the tiny10 can properly frame the zeroes
> and respond with the TPIIR correctly, it sounds like some protocol
> error occurred somewhere in between.
>
> Well if you have any further thoughts or do get it to work, I'd like
> to hear about it.
>
> --
> Regards,
> Darell Tan
>
>
> On Sat, Jun 30, 2012 at 7:23 PM, matthew venn <[hidden email]> wrote:
> > Dan, thanks for this.
> >
> >> If it's stuck in that loop, it's basically calling program_enable,
> >> which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
> >> to be set.
> >
> >
> > Yes what I'm seeing is the program enable section (detailed in that Atmel
> > pdf) called 64 times before avrdude gives up.
> >
> > So am I right in that the tiny10 is responding at some points? It's been
> > harder than usual to trace because all the comms happens on 1 wire. I'm
> > wondering if I could use some diodes on mosi and miso so I could scope
> > before they are merged.
> >
> > Someone at the hackspace I'm at (Bristol) has an avrisp mk2 which can do
> > TPI. So I'll try that. I've had exactly the same thing with another
> attiny10
> > so I think it must be my wiring or the software/pc side of things.
> >
> > One really odd thing I noticed about avrdude and the dasa config was that
> > when I was testing the outputs of the ftdi cable to check that I was
> getting
> > clock etc, was that if I had
> >
> > reset = 7
> > sck = 3
> >
> > that would work (both lines generated pulses), but with
> >
> > reset = 3
> > sck = 7
> >
> > only one of them would then generate signals. I've written those from
> memory
> > so I'm not entirely sure which way round they are but it seemed like a
> bug
> > to me at the time and now I'm wondering if there is something similar
> with
> > mosi and miso. Except that the mosi miso link check tests OK...
> >
> > Oh well, I'll get there in the end I imagine!
> > Thanks again,
> >
> > Matt
> >
> > --
> > Matthew Venn
> > mattvenn.net
>



--
Matthew Venn
mattvenn.net
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Matt,

I just realised that all the pins you mentioned are on the FTDI cable,
so am I right to assume you are using the FTDI cable instead of the
normal FTDI breakout board?

The main reason why the cable is not used is due to its limited number
of output signals. Out of 6 lines, 2 are for power, leaving with 4 for
data - 2 inputs, 2 outputs. For a programmer to work correctly, it
requires 3 outputs: RESET, SCK and MOSI. The line you've tied RESET to
is RX, which is an input pin. Normally, it's not possible for the RX
pin of normal serial ports to be driven as an output, but for the case
of FTDI I'm not sure. Instead, you could probably get away with tying
RESET low.

Out of curiousity, have you tried without the diode, and tying RESET
to GND instead? I have a feeling it's not really the diode but the
RESET line.

--
Regards,
Darell Tan


On Sun, Jul 1, 2012 at 9:14 PM, matthew venn <[hidden email]> wrote:

> I finally got it working, but I've no idea how!! If anyone can give me some
> ideas on why this works that would be great.
>
> Here is the output of avrdude:
>
> avrdude: AVR device initialized and ready to accept instructions
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C0 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 1E ]
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C1 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 90 ]
> bitbang_cmd_tpi(): [ 72 ] [ 00 ]
> bitbang_cmd_tpi(): [ F3 00 ] [ ]
> bitbang_cmd_tpi(): [ 68 C2 ] [ ]
> bitbang_cmd_tpi(): [ 69 3F ] [ ]
> bitbang_cmd_tpi(): [ 20 ] [ 03 ]
> avrdude: Device signature = 0x1e9003
>
> with avrdude command:
>
> ./bin/avrdude -C /etc/avrdude.conf -p t10 -c dasaftdi -P /dev/ttyUSB0 -v -v
> -v -v -q
>
> And definition of dasaftdi:
>
> programmer
>   id    = "dasaftdi";
>   desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
>   type  = serbb;
>   sck   = ~7; #green (rts)
>   reset = ~2; #yellow (rx)
>   mosi  = ~3; #orange (tx)
>   miso  = ~8; #brown (cts)
>
> The wiring from ftdi to attiny10 was the key part though:
>
> black (gnd) -> 2 (gnd)
> brown (cts) via a diode -> 1 (data)
> orange (tx) via a 1k resistor -> 1 (data)
> red (+5v) -> 5 (vcc)
> black (gnd) -> 6 (reset)
>
> The diode is important, without the programming fails with the previous
> error of getting stuck in the program enable loop for 64 times.
>
> The most confusing thing for me is that the diode has to allow current to
> flow from the miso to the mosi pin. But MOSI stands for master out slave in,
> so isn't this the wrong way round?
>
> But hooray it's working!!!
>
> Cheers,
> Matt
>
>
>
> On 30 June 2012 14:50, Darell Tan <[hidden email]> wrote:
>>
>> Hi Matt,
>>
>> Basically the reset line would only go down once, and will not be
>> released until the programming is done. The 2 other lines are the CLK
>> and DATA. Since the DATA line is only used by one party at a time, if
>> the tiny10 tried to transmit while avrdude was transmitting, it would
>> go into an error state and wait for a break. If you could probe the
>> lines with a logic analyzer, I'd be happy to take a look.
>>
>> This problem of yours is quite a puzzle, especially if both tiny10s
>> responded the same way. If the tiny10 can properly frame the zeroes
>> and respond with the TPIIR correctly, it sounds like some protocol
>> error occurred somewhere in between.
>>
>> Well if you have any further thoughts or do get it to work, I'd like
>> to hear about it.
>>
>> --
>> Regards,
>> Darell Tan
>>
>>
>> On Sat, Jun 30, 2012 at 7:23 PM, matthew venn <[hidden email]> wrote:
>> > Dan, thanks for this.
>> >
>> >> If it's stuck in that loop, it's basically calling program_enable,
>> >> which sends CMD_SKEY and expects the NVMEN bit in the TPISR register
>> >> to be set.
>> >
>> >
>> > Yes what I'm seeing is the program enable section (detailed in that
>> > Atmel
>> > pdf) called 64 times before avrdude gives up.
>> >
>> > So am I right in that the tiny10 is responding at some points? It's been
>> > harder than usual to trace because all the comms happens on 1 wire. I'm
>> > wondering if I could use some diodes on mosi and miso so I could scope
>> > before they are merged.
>> >
>> > Someone at the hackspace I'm at (Bristol) has an avrisp mk2 which can do
>> > TPI. So I'll try that. I've had exactly the same thing with another
>> > attiny10
>> > so I think it must be my wiring or the software/pc side of things.
>> >
>> > One really odd thing I noticed about avrdude and the dasa config was
>> > that
>> > when I was testing the outputs of the ftdi cable to check that I was
>> > getting
>> > clock etc, was that if I had
>> >
>> > reset = 7
>> > sck = 3
>> >
>> > that would work (both lines generated pulses), but with
>> >
>> > reset = 3
>> > sck = 7
>> >
>> > only one of them would then generate signals. I've written those from
>> > memory
>> > so I'm not entirely sure which way round they are but it seemed like a
>> > bug
>> > to me at the time and now I'm wondering if there is something similar
>> > with
>> > mosi and miso. Except that the mosi miso link check tests OK...
>> >
>> > Oh well, I'll get there in the end I imagine!
>> > Thanks again,
>> >
>> > Matt
>> >
>> > --
>> > Matthew Venn
>> > mattvenn.net
>
>
>
>
> --
> Matthew Venn
> mattvenn.net

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

matthew venn
Dan,

sorry I should have made that clear. I'm using the ftdi cable (5v version)
and I'm doing the reset by hand. Tying it low then trying to program.
Though I don't know why avrdude can't do it.

I used libusb to write a test program to test all the pins of the ftdi
cable, and can use all the 4 pins as outputs (didn't test inputs). However,
avrdude can't seem to make full use of all the pins so I skipped reset as I
can do this easily myself.

Cheers,
Matt

--
Matthew Venn
mattvenn.net
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Matt,

avrdude uses regular serial ports for bitbang programmers. The FTDI
chips appear as a virtual serial port, so they have to play by the
rules. The receive pin is used to receive, therefore it doesn't make
sense for a program to be able to control this line for output.

However, FTDIs also have another GPIO-like mode, in which all (?) pins
can be used for general purpose I/O. When used in this mode, the
serial port restrictions don't apply because they aren't serial ports
any more. This is what the "avrftdi" programmer uses, though TPI isn't
implemented there, and I think FT232R's are not supported. I may be
wrong about this though.

Well at least you got it to work :) If you want the convenience,
you'll have to use an FTDI breakout board instead.

--
Regards,
Darell Tan


On Tue, Jul 3, 2012 at 1:06 AM, matthew venn <[hidden email]> wrote:

> Dan,
>
> sorry I should have made that clear. I'm using the ftdi cable (5v version)
> and I'm doing the reset by hand. Tying it low then trying to program. Though
> I don't know why avrdude can't do it.
>
> I used libusb to write a test program to test all the pins of the ftdi
> cable, and can use all the 4 pins as outputs (didn't test inputs). However,
> avrdude can't seem to make full use of all the pins so I skipped reset as I
> can do this easily myself.
>
> Cheers,
> Matt
>
> --
> Matthew Venn
> mattvenn.net

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2
Hello,

> any more. This is what the "avrftdi" programmer uses, though TPI isn't
To clarify: avrftdi does not use bit banging, but a built-in serial engine which generates SPI-Signals in hardware.
TPI is not implemented yet. I just looked at the AVR918 application note and TPI could be implemented for avrftdi. However, I have at this point neither time nor the hardware.
> implemented there, and I think FT232R's are not supported. I may be
That is correct, but FT232H are supported - but not in TPI-mode.
> wrong about this though.

Best Regards,
Hannes Weisbach
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

René Liebscher
In reply to this post by Darell Tan
   Hi,
   FT232R is supported by ftdi_syncbb (see files ft245r.* in svn
   repository). But this does not support TPI.
   Regards
   Rene Liebscher
   Am 03.07.2012 06:43, schrieb Darell Tan:

Hi Matt,

avrdude uses regular serial ports for bitbang programmers. The FTDI
chips appear as a virtual serial port, so they have to play by the
rules. The receive pin is used to receive, therefore it doesn't make
sense for a program to be able to control this line for output.

However, FTDIs also have another GPIO-like mode, in which all (?) pins
can be used for general purpose I/O. When used in this mode, the
serial port restrictions don't apply because they aren't serial ports
any more. This is what the "avrftdi" programmer uses, though TPI isn't
implemented there, and I think FT232R's are not supported. I may be
wrong about this though.

Well at least you got it to work :) If you want the convenience,
you'll have to use an FTDI breakout board instead.

--
Regards,
Darell Tan


On Tue, Jul 3, 2012 at 1:06 AM, matthew venn [1]<[hidden email]> wrote:

Dan,

sorry I should have made that clear. I'm using the ftdi cable (5v version)
and I'm doing the reset by hand. Tying it low then trying to program. Though
I don't know why avrdude can't do it.

I used libusb to write a test program to test all the pins of the ftdi
cable, and can use all the 4 pins as outputs (didn't test inputs). However,
avrdude can't seem to make full use of all the pins so I skipped reset as I
can do this easily myself.

Cheers,
Matt

--
Matthew Venn
mattvenn.net

_______________________________________________
avrdude-dev mailing list
[2][hidden email]
[3]https://lists.nongnu.org/mailman/listinfo/avrdude-dev

References

   1. mailto:[hidden email]
   2. mailto:[hidden email]
   3. https://lists.nongnu.org/mailman/listinfo/avrdude-dev
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
In reply to this post by Hannes Weisbach-2
Hi Hannes,

I am aware that avrftdi doesn't really do bit-banging, which is why
it's faster than a normal bit-bang programmer. Fortunately ATtiny's
are tiny, so they are quite fast to read/write.

I took a quick look at the avrftdi code and realised it re-implemented
a lot of the pgm functions. In theory, it should have been enough to
implement just the cmd() function to "buffer" the op itself, to tell
the serial engine to generate the CLK and MOSI signals. And of course
the setpin() function to turn off/on LEDs or the RESET line.

If I had the time, I would implement TPI over avrftdi too, but it
seems like I need to copy/paste (or re-implement) the TPI logic into
avrftdi, which is not an elegant solution. If the code in avr.c could
be re-used, then it would have been really simple to get TPI working
for avrftdi.

--
Regards,
Darell Tan


On Tue, Jul 3, 2012 at 3:45 PM, Hannes Weisbach <[hidden email]> wrote:

> Hello,
>
>> any more. This is what the "avrftdi" programmer uses, though TPI isn't
> To clarify: avrftdi does not use bit banging, but a built-in serial engine which generates SPI-Signals in hardware.
> TPI is not implemented yet. I just looked at the AVR918 application note and TPI could be implemented for avrftdi. However, I have at this point neither time nor the hardware.
>> implemented there, and I think FT232R's are not supported. I may be
> That is correct, but FT232H are supported - but not in TPI-mode.
>> wrong about this though.
>
> Best Regards,
> Hannes Weisbach

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2

Am 03.07.2012 um 16:10 schrieb Darell Tan:

> Hi Hannes,
>
> I took a quick look at the avrftdi code and realised it re-implemented
> a lot of the pgm functions. In theory, it should have been enough to
> implement just the cmd() function to "buffer" the op itself, to tell
> the serial engine to generate the CLK and MOSI signals. And of course
> the setpin() function to turn off/on LEDs or the RESET line.
Yes. In fact, that is what my first prototype did. However, without paged read/write it would is rather slow. Especially with the old USB1.1-devices.
I tie the /RESET line to TMS, so you could even leave that out - it is changed automagically. And who needs LEDs? :)
>
> If I had the time, I would implement TPI over avrftdi too, but it
> seems like I need to copy/paste (or re-implement) the TPI logic into
> avrftdi, which is not an elegant solution. If the code in avr.c could
> be re-used, then it would have been really simple to get TPI working
> for avrftdi.
I've had only looked at the TPI protocol definition, not what is already available. But I agree that implementing TPI with avrdude would be rather hack-ish.
My current approach would be to transmit 2 bytes with the lower 12 bits as the TPI-frame and the higher 4 bits as '1' ("idle"). For reading, I would read in 2 bytes, with the TPI-frame in the upper 12 bits.
Of course, it would be possible to transmit one byte and 4 bits (since MPSSE can clock single bits). But I think this could incur more overhead (shifting bits around, more control information than data).
Luckily, PDI is very similar (without the /RESET line), so we could possibly get away with implementing the "physical" layer once.

Best regards,
Hannes


_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2
In reply to this post by Darell Tan

Am 03.07.2012 um 16:10 schrieb Darell Tan:

Hello,

> If I had the time, I would implement TPI over avrftdi too, but it
> seems like I need to copy/paste (or re-implement) the TPI logic into
> avrftdi, which is not an elegant solution. If the code in avr.c could
> be re-used, then it would have been really simple to get TPI working
> for avrftdi.

Yesterday I implemented prototypical TPI support in avrftdi (Again, thanks to Joerg for the Attiny10 breakout board). For now, I can only read the device ID (although fuses should be possible, too).
I agree, that TPI causes a lot of code duplication. I propose to split code into two layers "TPI access layer" and "TPI physical layer" - like Atmel did in the chip. See AVR918 (chapters 3.2 and 3.3) or Attiny10 datasheet (chapter 14.2). I imagine the access layer to be a generic implementation with callbacks into the physical layer. The physical layer has to implemented by every programmer. In the simplest case this would be a byte transmit and byte receive function. However, I suppose some programmer would benefit from "bulk transfers" (multiple bytes read or written).
I do not know if this is a viable approach with respect to "smart" programmers which have their own firmware. Maybe someone can comment on that.

Regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Hannes,

That's good news! Actually I am not sure if it would cause a lot of
duplication - it may be just a bit, which is fine.

The TPI code is currently implemented in 2 main files: bitbang.c and
avr.c. It is probably already split into the access layer and physical
layer.

In avr.c, TPI code is in these functions:
- avr_read_byte_default
- avr_read
- avr_write_byte_default
- avr_write

In bitbang.c, the TPI "physical layer" is in these functions:
- bitbang_tpi_clk
- bitbang_tpi_tx
- bitbang_tpi_rx
- bitbang_cmd_tpi (exposed in pgm struct)

The only place where code is duplicated is in these functions:
- bitbang_chip_erase
- bitbang_program_enable
- bitbang_initialize

The cmd_tpi is the main function which should be implemented in
avrftdi for the physical layer. As for the chip_erase and
program_enable, there is no avr_xxx common function available for
these, so the code has to be duplicated here. The bitbang_initialize
also needs to be implemented to enable the TPI interface.

All the code in avr.c is already calling cmd_tpi, so there's not much
problems there. There's no real paged reads/writes, since if avr_read
and avr_write is called with a block of contiguous data, the reads and
writes can be performed faster using post-increment.

Am I missing anything here?

--
Regards,
Darell Tan


On Sun, Jul 8, 2012 at 8:10 PM, Hannes Weisbach <[hidden email]> wrote:

>
> Am 03.07.2012 um 16:10 schrieb Darell Tan:
>
> Hello,
>
>> If I had the time, I would implement TPI over avrftdi too, but it
>> seems like I need to copy/paste (or re-implement) the TPI logic into
>> avrftdi, which is not an elegant solution. If the code in avr.c could
>> be re-used, then it would have been really simple to get TPI working
>> for avrftdi.
>
> Yesterday I implemented prototypical TPI support in avrftdi (Again, thanks to Joerg for the Attiny10 breakout board). For now, I can only read the device ID (although fuses should be possible, too).
> I agree, that TPI causes a lot of code duplication. I propose to split code into two layers "TPI access layer" and "TPI physical layer" - like Atmel did in the chip. See AVR918 (chapters 3.2 and 3.3) or Attiny10 datasheet (chapter 14.2). I imagine the access layer to be a generic implementation with callbacks into the physical layer. The physical layer has to implemented by every programmer. In the simplest case this would be a byte transmit and byte receive function. However, I suppose some programmer would benefit from "bulk transfers" (multiple bytes read or written).
> I do not know if this is a viable approach with respect to "smart" programmers which have their own firmware. Maybe someone can comment on that.
>
> Regards,
> Hannes

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2

Am 09.07.2012 um 10:53 schrieb Darell Tan:

> Hi Hannes,
>
> That's good news! Actually I am not sure if it would cause a lot of
> duplication - it may be just a bit, which is fine.
It's rather a lot. I essentially copied the code from usbasp and renamed everything from usbasp to avrftdi. The only thing /really/ new thing are read/write byte functions, which of course, are programmer-specific. This is essentially what I would call the "TPI access layer" in avrdude.
>
> The TPI code is currently implemented in 2 main files: bitbang.c and
> avr.c. It is probably already split into the access layer and physical
> layer.
Nope, 3. usbasp also implements TPI and duplicates the below-mentioned initialize, erase and enable functions.
>
> In bitbang.c, the TPI "physical layer" is in these functions:
> - bitbang_tpi_clk
> - bitbang_tpi_tx
> - bitbang_tpi_rx
> - bitbang_cmd_tpi (exposed in pgm struct)
Maybe exposing cmd_tpi in the PROGRAMMER struct is sufficient, and read/write byte commands (as suggested by me in my previous mail) are not necessary.
>
> The only place where code is duplicated is in these functions:
> - bitbang_chip_erase
> - bitbang_program_enable
> - bitbang_initialize
Correct. But in the end all these functions could be replaced by a generic version, which calls pgm->cmd_tpi.
Probably paged programming/loading could also implemented with single pgm->cmd_tpi callbacks (instead of using bulk transfers).
I'm not sure how to integrate paged programming in the existing framework.
I don't like the way how, for example usbasp, does change callbacks (simplified):

if((AVRPART*)->flags & AVRPART_HAS_TPI)
{
...
    pgm->program_enable = usbasp_tpi_program_enable;
    pgm->chip_erase     = usbasp_tpi_chip_erase;
    pgm->cmd            = usbasp_tpi_cmd;
    pgm->read_byte      = usbasp_tpi_read_byte;
    pgm->write_byte     = usbasp_tpi_write_byte;
    pgm->paged_write    = usbasp_tpi_paged_write;
    pgm->paged_load     = usbasp_tpi_paged_load;
    pgm->set_sck_period = usbasp_tpi_set_sck_period;
...
} else
...

avrftdi doesn't have as much callbacks for TPI (yet, ... working on it ...).

So, I don't like that. The next thing to do would be using the "standard" page programming function and putting something like:
...
((AVRPART*)->flags & AVRPART_HAS_TPI)
        do_tpi_page_programming(...);
...
which is not elegant either. So I guess I would like a callback in the programmer struct for every programming mechanism (ISP, TPI, PDI, JTAG, ...) the programmer supports.
However I have only a limited overview on avrdude and possible problems associated with it.
>
> The cmd_tpi is the main function which should be implemented in
> avrftdi for the physical layer. As for the chip_erase and
> program_enable, there is no avr_xxx common function available for
> these, so the code has to be duplicated here. The bitbang_initialize
> also needs to be implemented to enable the TPI interface.
That's what I want: avr.c /should/ implement chip_erase and program_enable, because they are generic when relying on the PROGRAMMER->cmd_tpi callback.
A value for guard time bits could be put in the PROGRAMMER struct, so that the code in avr.c knows about what the programmer actually needs.
>
> All the code in avr.c is already calling cmd_tpi, so there's not much
> problems there. There's no real paged reads/writes, since if avr_read
> and avr_write is called with a block of contiguous data, the reads and
> writes can be performed faster using post-increment.
Bundling reads and writes with post-increment enabled should be way faster when only one USB transfer is used. For my 4232H device (USB 2.0), programming an AVR with single byte instruction (using ISP however) is not much slower than paged programming. The difference in speed is much more clearly using a USB 1.1 device (2232C, in my case).

Regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
Hi Hannes,

Can I ask why you did not simply implement cmd_tpi, chip_erase,
program_enable and initialize functions accordingly?

When avrdude is called to read, avr_read() is called and within
avr_read() there is already code that checks for cmd_tpi and calls it.
If you implement the above-mentioned functions, you should immediately
be able to read/write using TPI. The same thing happens for
avr_write()... unless I totally misunderstood how avrdude or avrftdi
works.


> I don't like the way how, for example usbasp, does change callbacks (simplified):
>
> if((AVRPART*)->flags & AVRPART_HAS_TPI)
> {
> ...
>     pgm->program_enable = usbasp_tpi_program_enable;
>     pgm->chip_erase     = usbasp_tpi_chip_erase;
>     pgm->cmd            = usbasp_tpi_cmd;
>     pgm->read_byte      = usbasp_tpi_read_byte;
>     pgm->write_byte     = usbasp_tpi_write_byte;
>     pgm->paged_write    = usbasp_tpi_paged_write;
>     pgm->paged_load     = usbasp_tpi_paged_load;
>     pgm->set_sck_period = usbasp_tpi_set_sck_period;
> ...
> } else
> ...
>

Yes I feel the same way about this piece of code. After doing a quick
search in the source code, I realised that usbasp re-implements the
TPI protocol again. I guess it could be refactored to rely on a single
protocol implementation in avr.c and just implement cmd_tpi() as well
(I haven't really looked at the code in detail).

The reason why I am emphasizing on cmd_tpi() is because when I read
the avrdude code, I believe this is the way it was designed to be.
Each of the opcodes are in the config file, which can be accessed by
the mem->op[] array, and cmd() is called with the appropriate opcode
which transmits it over the physical layer, whether bitbang or SPI or
MPSSE.

When I implemented TPI, I followed the same design, except that I
introduced cmd_tpi instead of "overloading" cmd(). Another reason is
due to the function prototype, which was fixed to cmd[4] and res[4],
which are not necessarily the case for TPI.

--
Regards,
Darell Tan


On Mon, Jul 9, 2012 at 8:35 PM, Hannes Weisbach <[hidden email]> wrote:

>
> Am 09.07.2012 um 10:53 schrieb Darell Tan:
>
>> Hi Hannes,
>>
>> That's good news! Actually I am not sure if it would cause a lot of
>> duplication - it may be just a bit, which is fine.
> It's rather a lot. I essentially copied the code from usbasp and renamed everything from usbasp to avrftdi. The only thing /really/ new thing are read/write byte functions, which of course, are programmer-specific. This is essentially what I would call the "TPI access layer" in avrdude.
>>
>> The TPI code is currently implemented in 2 main files: bitbang.c and
>> avr.c. It is probably already split into the access layer and physical
>> layer.
> Nope, 3. usbasp also implements TPI and duplicates the below-mentioned initialize, erase and enable functions.
>>
>> In bitbang.c, the TPI "physical layer" is in these functions:
>> - bitbang_tpi_clk
>> - bitbang_tpi_tx
>> - bitbang_tpi_rx
>> - bitbang_cmd_tpi (exposed in pgm struct)
> Maybe exposing cmd_tpi in the PROGRAMMER struct is sufficient, and read/write byte commands (as suggested by me in my previous mail) are not necessary.
>>
>> The only place where code is duplicated is in these functions:
>> - bitbang_chip_erase
>> - bitbang_program_enable
>> - bitbang_initialize
> Correct. But in the end all these functions could be replaced by a generic version, which calls pgm->cmd_tpi.
> Probably paged programming/loading could also implemented with single pgm->cmd_tpi callbacks (instead of using bulk transfers).
> I'm not sure how to integrate paged programming in the existing framework.
> I don't like the way how, for example usbasp, does change callbacks (simplified):
>
> if((AVRPART*)->flags & AVRPART_HAS_TPI)
> {
> ...
>     pgm->program_enable = usbasp_tpi_program_enable;
>     pgm->chip_erase     = usbasp_tpi_chip_erase;
>     pgm->cmd            = usbasp_tpi_cmd;
>     pgm->read_byte      = usbasp_tpi_read_byte;
>     pgm->write_byte     = usbasp_tpi_write_byte;
>     pgm->paged_write    = usbasp_tpi_paged_write;
>     pgm->paged_load     = usbasp_tpi_paged_load;
>     pgm->set_sck_period = usbasp_tpi_set_sck_period;
> ...
> } else
> ...
>
> avrftdi doesn't have as much callbacks for TPI (yet, ... working on it ...).
>
> So, I don't like that. The next thing to do would be using the "standard" page programming function and putting something like:
> ...
> ((AVRPART*)->flags & AVRPART_HAS_TPI)
>         do_tpi_page_programming(...);
> ...
> which is not elegant either. So I guess I would like a callback in the programmer struct for every programming mechanism (ISP, TPI, PDI, JTAG, ...) the programmer supports.
> However I have only a limited overview on avrdude and possible problems associated with it.
>>
>> The cmd_tpi is the main function which should be implemented in
>> avrftdi for the physical layer. As for the chip_erase and
>> program_enable, there is no avr_xxx common function available for
>> these, so the code has to be duplicated here. The bitbang_initialize
>> also needs to be implemented to enable the TPI interface.
> That's what I want: avr.c /should/ implement chip_erase and program_enable, because they are generic when relying on the PROGRAMMER->cmd_tpi callback.
> A value for guard time bits could be put in the PROGRAMMER struct, so that the code in avr.c knows about what the programmer actually needs.
>>
>> All the code in avr.c is already calling cmd_tpi, so there's not much
>> problems there. There's no real paged reads/writes, since if avr_read
>> and avr_write is called with a block of contiguous data, the reads and
>> writes can be performed faster using post-increment.
> Bundling reads and writes with post-increment enabled should be way faster when only one USB transfer is used. For my 4232H device (USB 2.0), programming an AVR with single byte instruction (using ISP however) is not much slower than paged programming. The difference in speed is much more clearly using a USB 1.1 device (2232C, in my case).
>
> Regards,
> Hannes

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2

Am 09.07.2012 um 16:01 schrieb Darell Tan:

> Hi Hannes,
>
> Can I ask why you did not simply implement cmd_tpi, chip_erase,
> program_enable and initialize functions accordingly?
I did and I never said otherwise. I just don't like it, because it causes much code duplication. Have a look at what bitbang_chip_erase does in the TPI section and what usbasp_tpi_program_enable does.

As far as I can tell your understanding of avrftdi and avrdude is correct :)

Cheers,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
On Mon, Jul 9, 2012 at 10:29 PM, Hannes Weisbach
<[hidden email]> wrote:
>
> Am 09.07.2012 um 16:01 schrieb Darell Tan:
>
>> Hi Hannes,
>>
>> Can I ask why you did not simply implement cmd_tpi, chip_erase,
>> program_enable and initialize functions accordingly?
> I did and I never said otherwise. I just don't like it, because it causes much code duplication. Have a look at what bitbang_chip_erase does in the TPI section and what usbasp_tpi_program_enable does.

I see, then I misunderstood you because you mentioned you "essentially
copied the code from usbasp and renamed everything from usbasp to
avrftdi" which includes usbasp_tpi_read/write_byte,
usbasp_tpi_paged_read/write as well.

As for common code, I think there could be a common chip_erase and
program_enable (like avr_chip_erase or something). It may not be the
best solution, but it's definitely better than having duplicate code
in the different programmers.

>
> As far as I can tell your understanding of avrftdi and avrdude is correct :)
>
> Cheers,
> Hannes

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Hannes Weisbach-2

Am 09.07.2012 um 17:17 schrieb Darell Tan:

> On Mon, Jul 9, 2012 at 10:29 PM, Hannes Weisbach
> <[hidden email]> wrote:
>>
>> Am 09.07.2012 um 16:01 schrieb Darell Tan:
>>
>>> Hi Hannes,
>>>
>>> Can I ask why you did not simply implement cmd_tpi, chip_erase,
>>> program_enable and initialize functions accordingly?
>> I did and I never said otherwise. I just don't like it, because it causes much code duplication. Have a look at what bitbang_chip_erase does in the TPI section and what usbasp_tpi_program_enable does.
>
> I see, then I misunderstood you because you mentioned you "essentially
> copied the code from usbasp and renamed everything from usbasp to
> avrftdi" which includes usbasp_tpi_read/write_byte,
> usbasp_tpi_paged_read/write as well.
Ok. To clarify:
- I copied tpi_program_enable(), tpi_nvm_waitbusy(), tpi_chip_erase() and cmd_tpi(). I renamed them from usbasp_* to avrftdi_* (except cmd_tpi, which I got from bitbang.c and I also changed the code a little).
- I've implemented pendants to usbasp_tpi_send_byte() and usbasp_tpi_recv_byte() for avrftdi ("physical layer"). In contrast to usbasp I do parity check and return error codes (maybe usbasp does it in the firmware - at least I believe it is firmware-based).
- As I said in my first email, I only read out the device ID (command line: "avrdude -c 4232h -p attiny10") and indeed I have not yet implemented paged read/write access (partly because it was late, partly because I couldn't think of an elegant way).
Sorry for not being more clearly earlier.
>
> As for common code, I think there could be a common chip_erase and
> program_enable (like avr_chip_erase or something). It may not be the
> best solution, but it's definitely better than having duplicate code
> in the different programmers.
Maybe a maintainer can comment on that issue?

Regards,
Hannes
_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
Reply | Threaded
Open this post in threaded view
|

Re: attiny10 with ftdi and bitbang

Darell Tan
On Mon, Jul 9, 2012 at 11:42 PM, Hannes Weisbach
<[hidden email]> wrote:

> Ok. To clarify:
> - I copied tpi_program_enable(), tpi_nvm_waitbusy(), tpi_chip_erase() and cmd_tpi(). I renamed them from usbasp_* to avrftdi_* (except cmd_tpi, which I got from bitbang.c and I also changed the code a little).
> - I've implemented pendants to usbasp_tpi_send_byte() and usbasp_tpi_recv_byte() for avrftdi ("physical layer"). In contrast to usbasp I do parity check and return error codes (maybe usbasp does it in the firmware - at least I believe it is firmware-based).
> - As I said in my first email, I only read out the device ID (command line: "avrdude -c 4232h -p attiny10") and indeed I have not yet implemented paged read/write access (partly because it was late, partly because I couldn't think of an elegant way).
> Sorry for not being more clearly earlier.

No problems, I was just wondering.

"Paged" read and writes are being handled through the use of
post-increment instructions. In this mode, it allows an address to be
set once and subsequent reads automatically increment the address. The
same goes for write.

The relevant code is already in avr_read and avr_write functions.

--
Regards,
Darell Tan

_______________________________________________
avrdude-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avrdude-dev
12