The AVRispmkII now supports PDI programming for xmega, even through avrdude.
I might humbly suggest that this would be a nice, if not easy, feature to consider for a future revision of the USBtiny. :D
Feature suggestion: PDI
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
-
- Posts: 1
- Joined: Sat Aug 07, 2010 4:53 pm
Re: Feature suggestion: PDI
i need to fresh this up!
is PDI planned yet or is it impossible?
Greetings
user
is PDI planned yet or is it impossible?
Greetings
user
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Feature suggestion: PDI
we dont know...but we will look into it!
-
- Posts: 2
- Joined: Sun Mar 30, 2008 2:36 am
Re: Feature suggestion: PDI
So, I recently ran into a project where I need the extra speed of an XMEGA, and me and all my friends have gotten into this USB Tiny ISP jazz... at least the ones who outgrew the arduino.
I'll be getting it soon, at least as soon as some of them come into Digikey. It looks like the programming header is pin-compatible with the PDI interface (at least the one boston android is such a fan of) and I had good luck last time when I was bit banging stuff to/from an avr using the tiny isp in the past.
While I understand bit banging is a bit slow (as per why it's not used for typical AVR programming using the usbtinyisp) this is definitely the approach I'm going to take when trying to get some PDI going.
I tried making sense of the stk500v2.c in AVRDude, but it seem to just pass high level commands on, rather than bit banging or anything particularly low level.
I'm at a complete loss on the protocol for PDI, though. The datasheets I've looked at have no more than a paragraph on PDI or the maximum PDI speed based on voltage. Unless I can get a spec and get some bits pushed out to the thing - at least to the beginnings of an echo or hello world, I'm stuck.
I think the chance of success for me to do this are in the 10% range if I do it alone, so I could totally use some help. In the event this works out, I'd have no problem chatting to some of the people over at AVRdude and with sufficient review, maybe having an updated usbtiny.c or a new usbtinyPDI.c.
Anyone want to hop in on this?
*EDIT* No sooner do I spend 5 minutes of research after my hour of research to find:
Also -> www.atmel.com/dyn/resources/prod_documents/doc8133.pdf -> looks useful
*Sigh* looks like new firmware will be mandatory at the least .
I'll be getting it soon, at least as soon as some of them come into Digikey. It looks like the programming header is pin-compatible with the PDI interface (at least the one boston android is such a fan of) and I had good luck last time when I was bit banging stuff to/from an avr using the tiny isp in the past.
While I understand bit banging is a bit slow (as per why it's not used for typical AVR programming using the usbtinyisp) this is definitely the approach I'm going to take when trying to get some PDI going.
I tried making sense of the stk500v2.c in AVRDude, but it seem to just pass high level commands on, rather than bit banging or anything particularly low level.
I'm at a complete loss on the protocol for PDI, though. The datasheets I've looked at have no more than a paragraph on PDI or the maximum PDI speed based on voltage. Unless I can get a spec and get some bits pushed out to the thing - at least to the beginnings of an echo or hello world, I'm stuck.
I think the chance of success for me to do this are in the 10% range if I do it alone, so I could totally use some help. In the event this works out, I'd have no problem chatting to some of the people over at AVRdude and with sufficient review, maybe having an updated usbtiny.c or a new usbtinyPDI.c.
Anyone want to hop in on this?
*EDIT* No sooner do I spend 5 minutes of research after my hour of research to find:
(From http://www.equinox-tech.com/downloads/e ... 070510.pdf )The ‘PDI – Clock’ is a clock signal which is continuously generated by the programmer during PDI programming. This clock is fed from the programmer into the PDI_CLK (RESET) pin of the target XMEGA device. The clock signal must be a continuous waveform with a frequency >= 10 kHz, otherwise the target XMEGA device will exit PDI programming mode.
Also -> www.atmel.com/dyn/resources/prod_documents/doc8133.pdf -> looks useful
*Sigh* looks like new firmware will be mandatory at the least .
- rolando
- Posts: 15
- Joined: Tue Sep 21, 2010 10:48 am
Re: Feature suggestion: PDI
Any update on this? I got an empty xmega128 and I was thinking on getting a USBTiny to program it... but it looks that there's still no support for PDI, is it?
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Feature suggestion: PDI
usbtiny does not and at least in this revision, never support PDI - there is no space left
- rolando
- Posts: 15
- Joined: Tue Sep 21, 2010 10:48 am
Re: Feature suggestion: PDI
it's a shame... it looks like I'll have to grab a mkii then. Any other programmer that might be worth looking into? (in the same price range)adafruit wrote:usbtiny does not and at least in this revision, never support PDI - there is no space left
-
- Posts: 130
- Joined: Wed Feb 25, 2009 10:27 pm
Re: Feature suggestion: PDI
Could it be posable to have a different firmware to just do PDI?
- kscharf
- Posts: 277
- Joined: Wed Sep 10, 2008 10:29 am
Re: Feature suggestion: PDI
The USBtiny is based on the ATtiny2313. Atmel has an upgrade part in the wings (ATtiny4313) which will hopefully be available soon. I guess having double the program space will enable fitting the PDI mode in as well. Something to consider....
-
- Posts: 12151
- Joined: Thu Apr 06, 2006 4:21 pm
Re: Feature suggestion: PDI
If someone can write a version of the usbtiny code that supports PDI we'll definitely work that in. we dont have any PDI-able devices here
Please be positive and constructive with your questions and comments.