Dear AVRFreaks
I have just read about the new Attiny10 with TPI programming interface, and was wondering what programming tool could be used. I have tried to see if www.ic-board.de had one with TPI interface but couldn't find any. For those who already have tried programming the new ATTiny10, how did you do it? What tool did you use?
Best regards
Pindsen
STK600 is the officially listed programmer. Though I suspect the STK500 and AVRISPmkII firmwares could be adjusted to support it as well.
For those who already have tried programming the new ATTiny10, how did you do it?
It's intriguing isn't it that if you run the AVR programmer dialog in "disconnected mode" for STK500 and pick any particular AVR you get offered various programming methods like "PP/HVSP", "ISP", etc. Meanwhile, though "tiny10" appears in the list if you select that the program method box is blank.
On the one hand it's interesting that the STK500 apparently "knows" about the tiny10 but on the other it doesn't know how to communicate.
On the one hand it's interesting that the STK500 apparently "knows" about the tiny10
Using the ATtiny12 Adapter for Emulating the ATtiny10/11
The ATtiny10 and 11 are both subsets of ATtiny12. Therefore it is possible to select the ATtiny12 device when configuring the ICE200 to support either ATtiny10 or ATtiny11. These devices all have the same pinout, but ATtiny10/11 does not have the following features :
;ATtiny11
.db 0x50,0
;ATtiny10
.db 0x51,0
;ATtiny12
.db 0x55,0
;ATtiny15
.db 0x56,0
Oh what a tangled web we weave... Have I mentioned how stupid the whole thing is?? Maybe once or twice.
> Remeber that the old Tiny 10 has been around for about 10 years!
Did anyone see any real parts of them, ever?
But I agree, re-using a part number isn't a good idea (IMO).
The ATtiny10 is roughly half the cost of the ATtiny12, so it is very appealing if you only need the 4 I/O pins. Unfortunately, getting info on the development tools is time consuming and overall, very difficult. I'm a newbie and I had hoped to use the AVRDragon, but it doesn't support the 10.
I've spent too much time on the website trying to figure out which h/w platform to order.
Studio 4 supports it, but I haven't ordered any hardware platform yet. Developing on the Tiny12 seems like a good idea, but does anyone have any good ideas which development platform will allow development on the Tiny12 then move the code to the Tiny10 later?
I had hoped to use the AVRDragon, but it doesn't support the 10.
I've spent too much time on the website trying to figure out which h/w platform to order.
Yet the STK-600 and associated programming adapter are mentioned right in the news release for the tiny10.
I had hoped to use the AVRDragon, but it doesn't support the 10.
I've spent too much time on the website trying to figure out which h/w platform to order.
The ATtiny10 is roughly half the cost of the ATtiny12, so it is very appealing
Developing on the Tiny12 seems like a good idea, but does anyone have any good ideas which development platform will allow development on the Tiny12 then move the code to the Tiny10 later?
I wouldn't try developing for the tiny12 as it has no SRAM while the tiny10 has 32 bytes of it. I would suggest using the tiny13, as it does have SRAM (64 bytes). It also has EEPROM, but you don't have to use it.
Take a look at the parametric product table: http://atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC#791
Use a "real" AVR like the Tiny25, IMO. For sample quantities it is a few pennies more and offers much more.
I wouldn't expect to see a real chip for some months
PS "no one" means a contributor to this board who isn't an Atmel employee.
Perhaps we should open a book.
Cliff, I'd guess you could get a couple if you tell Atmel it is between the Tiny10 and the PIC10F for a kazillion of your widgets. Heck, they'd re-label >>some<< kind of SOT-23 device just to show you silicon. ;)
https://www.avrfreaks.net/index.p...
Quote:Also says samples available now, and production quantities in May.
LOL--shall we start a pool? Lessee, a prize to the first person that actually receives a sample (and maybe we should qualify that to be the first one to get a blinky running, which would imply availability of a programmer and a toolchain). And a prize for the closest date to when the Atmel North American Stock Check shows at least one distributor with stock.
I've got to see what I could offer. Perhaps a printed 1997 AVR databook--the kiddies have prbably never >>seen<< a printed databook. Wink
Lee
Lee
oh come on Lee, getting the chip is enough, as we ALREADY HAVE the development tools. The assembler is the same as we already use. AVR Studio/simulator2 supports the tiny10, and the stk600 is said to support the programming mode. So Given that, it would only take a couple of minutes to get a "blinky" program running on a real chip. I don't see how doing that makes it any more real than having the chip itself.
If you wish to test the tools, you can do so now. (less the TPI programming interface of the STK600)
I don't see how doing that makes it any more real than having the chip itself.
Who said anything about theory. With the exception of TPI, it is all verifiable now.
the stk600 is said to support the programming mode.
[edit]128MB of AVRStudio 4.16 download, there it is! Right in the STK600 section: "ATtiny10 STK600-ATTINY10 TPI " with a promised socket card.
I don't see how doing that makes it any more real than having the chip itself.
It is kind of ironic that the "touts" of the Tiny10 in the other thread put forward the cost savings of the Tiny10 over the Tiny25. Let's say it is $0.10 in moderate quantity. STK600 is $200 so with the numbers above you'd need to have a build of 2000 pieces to break even.
Hopefully, the ATAVRISP2 will get an update to support its claim of being able to handle all 8-bit AVRs.
Lee
I can say, that the XML files for the tiny10 list both simulator2 and the STK600.
As for the assembler, I don't see anything that would disallow the low registers, but may be implied by the following pragma.
#pragma AVRPART CORE CORE_VERSION AVR8L_0
[There are no working register definitions in the inc file, so they must be coming from somewhere else]
Also note that I'm running 4.16, which lists the t10 as supported by the STK600, and also has a section on TPI programming in the STK600 help files.
Then some of us should have all the needed toyz when we get the little bugger into our sweaty palms. So, if Cliff is going for "Tiny-Ten in Twenty-Ten", what's your guess? I'll guess that Atmel really messed up on the Xmega and this will be better. I'll go with 18-July-2009.
Lee
AAAAIIIIIYY, glitcher--did you see this in the TPI section?
Note: TPI is only supported on-board, i.e it is not possible to program a device on an external board through the TPI interface.
Then what do you do with it? Solder the SOT-23 into your app and run. Now, better be right the first time, or you have to unsolder it and put back into the adapter?!? [Am I missing something here?]
Lee
And you save exactly how many cents at the end of the day? I'd have to have a pretty compelling reason (maybe a 1,000,000 plus application?) to bother with this and it's half-baked 16 register set which is pretty much going to limit it to Asm use.
The announcement lists the STK-600 at $159, Tiny10-STK600 adapter $49.
Though everyone seems to be selling the STK-600 at $199, and the adapters at $99. Perhaps this is indication of an upcoming price-drop?
Thanks for the helpful posts everyone :). Judging from the responses, it seems like I'm ahead of the curve looking at the ATtiny10 (and behind the curve with development tools).
Having no experience with Atmel, I didn't expect the uncoordinated release of vaporware. I'll look at the ATtiny25 at Lee's suggestion.
A little background is probably in order:
I figured I would start the project using the AVRDragon since this is all on spec. I went for the low cost tool instead of the STK600 which will be my own expense. My initial choice was the PIC10F family (no offense!) until I came across the ATtiny43U 0.7V announcement. I needed the low voltage performance, but even after putting the boost circuit components in, it provides only 30mA to peripherals -not enough (and it had way too many more pins than I needed). So I decided to go for a separate boost converter and the Tiny10. Cost was still below that of PIC10F or the 43U.
My product is extremely cost sensitive, so the more $ I take out during the initial design effort, the better. My total target cost is under $3 so $0.30 less for the Tiny10 is a big savings.
To Lee: Yes - I'd like to make a kazillion of these, but I've got to prove that it works as I think it should.
As a newbie to both the PIC and the AVR, I found the PIC website so much easier to find what I needed - including budget pricing. Is there budget pricing on Atmel's site? WHere?
Thanks to all,
Bob
I'd have to have a pretty compelling reason (maybe a 1,000,000 plus application?) to bother with this and it's half-baked 16 register set which is pretty much going to limit it to Asm use.
Given that it only has 512 instruction words of flash, I don't see that as a downside. With the small size, the types of applications here are going to be small and simple, and likely written in assembly anyway.
It is more likely the limited 32 bytes of RAM, and not the limited registers that's going to preclude a C compiler (or any other language). There is no reason why a compiler couldn't be constrained to use the fewer registers. Or are you specifically referring to GCC?
likely written in assembly anyway.
The dual-stack model of CV is gonna be real scary with that little SRAM. I write big mains anyway so it may not bother my style much.
If GCC with its sing;e-stack model and aggressive inlining can be coerced into a good register model it could do fine. The stumbling block might be the "zero" register stuff throughout.
Lee
I'll look at the ATtiny25 at Lee's suggestion.
Samples I got, information on the STK600 adapter I cannot find. The user guide notes you need to use two 6-pin connectors, possibly as the reset signal is left off the TPI connector. But as noted above, no off board programming. Why do I feel the support for this part is rather ragged?
Just as a general FYI, I was quoted 16weeks lead-time for production quantities.
I've requested samples, will see how long it takes till I get them. Don't have a STK600, going to try and make my own TPI programmer using another AVR.
But as noted above, no off board programming.
Samples I got,
Lee
I suppose that I could do it with simulation, but nothing says success like having a piece of hardware to demo.
Cliff pooh-poohed the blinky-LED requirement for the winner as being trivial.
I think you'll find that was glitch
oh come on Lee, getting the chip is enough, as we ALREADY HAVE the development tools.
FWIW, I checked Studio 4 and while you can set up a new ASM project based on Simulator 2 and ATTiny10, none of the other programmer/debug platforms allows that ATTiny10 exists. STK600 documentation knows about the programming interface, but until the S4 knows to program the hardware, burning parts through Studio 4 isn't in the cards.
> Or are you specifically referring to GCC?
GCC might even have an advantage here over the entire "competition". As Lee
already noticed, all other compilers are using a dual-stack approach, while GCC
(in its Unix tradition) uses a single stack for both, the return PC addresses
as well as parameters (only if needed, of course). With a one-stack model, you
can always grow the stack from top of RAM, and static allocations from bottom
of RAM, gaining the largest possible stack size. With a two-stack model, one
of them has to be preallocated large enough, and only the second one can be
automatic in size.
The bigger issue is that the different register model requires a complete rewrite
of the backend code for that processor, regardless of which compiler you are using.
That's a lot of work for just a single CPU type (the more, given the likelihood
users will prefer programming it in assembly anyway due to its constrained resources).
The bigger issue is that the different register model requires a complete rewrite
of the backend code for that processor, regardless of which compiler you are using.
Re the stack: With that few bytes of SRAM each location is precious, and it will be like "cycle counting": regardless of single/dual stack model, stack usage will need to be calculated very closely.
Lee
> as the low registers are generally global register variables
> (including "bit") so that is the feature that is lost.
OK, if the compiler could never use the lower registers anyway (except where
requested explicitly by the developer), that's true. But then, you lose
about half of the valuable registers for everything but the ATtiny10...
But then, you lose
about half of the valuable registers for everything but the ATtiny10...
Lee
ATtiny10 Programmer question to Atmel support:
No responses from the AVR Support folks (avr@atmel.com) except for the acknowledgement email and a case number. No call from the FAE either. How long does Atmel usually take to respond to support questions?
With little info to go on, I don't plan to spend the $200 on the STK600 - plus whatever $99 adapters are needed. I'm not convinced that it will all work yet anyway. I really liked the features of that little chip, but since I have everything I need for the PICF206, I'll probably start there.
I will post when I hear from the AVR support folks...
Bob
My guess is that other matters are keeping support for this part a little slow, like nobody proposing a $1M contract, in which case of course we will answer your question now. Not that Atmel is snubbing us, it is just that they have business realities in a nasty world economy to pay attention to. Said that, I still want to play with my new toy and my boss isn't footing any expense without a good justification. Curiousity doesn't come under that heading. :-(
I don't think they are snubbung us either. The "other matter" is more likely that they are trying to figure out how to deal with the Tiny10 themselves. I've seen bleeding edge first release products that simply don't work the way you expect them. My guess is that they simply have bugs/problems with it.
Bob
Would the ATTiny10 be capable of handling SPI or I2C? I didn't see anything mentioned in the docs.. but that's hardware support I guess. I imagine these could be implemented in software?
received attiny10 samples this morning. they're very small and only marked with T 10 C. I will be etching a board and eagerly awaiting both programming and compiling instructions! Has anyone successfully programmed one of these yet? -Bob
received attiny10 samples this morning.
Lee
Quote:
received attiny10 samples this morning.
You are then in the running for the "blinky LED off of Tiny10" prize.
oh yeah? what are the stakes?
received attiny10 samples this morning. they're very small and only marked with T 10 C. I will be etching a board and eagerly awaiting both programming and compiling instructions! Has anyone successfully programmed one of these yet? -Bob
Grrrr - I go through hundreds of AVRs a month and I've not even -heard- back from Atmel about my sample request from ages ago :x :x :evil:
These chips will completely change the setup of my production and I'm eagerly wanting to get them in 250+ quantities to start out with, but ooooh no, Atmel isn't interested in talking to me :( *jealous*
Atmel isn't interested in talking to me
Is this topic still open?
I believe that I have achieved a "blinky" on an ATTiny10.
Samples arrived early last week from NuHorizons, have been making progress each evening until success about 15 minutes ago :-)
Technology chain:
Avr Studio 4.16 (assembler 2)
-> Avr Dragon over USB
-> AtTiny2313 over DebugWIRE
-> AtTiny10 over TPI
-> LED
Cool! I'll have to dig into my "junk bin" for a suitable reward. Send me a PM if you care to.
Let me get this straight: Did you write a '2313 program to implement TPI, and then sent Blinky to the '10 from the '2313? Or am I misunderstanding?
Lee
Yes, that was my technique.
STK600-tiny10 is not even on atmels own tools (starter kit) list - so I read up on the two TPI chapters in the tiny10 datasheet.
Last nights code (lines 294-395 of ATTiny2313 app):
TinyCode:
ldi R16,4 //04 E0
out 0x01,R16 //01 B9 -- DDRB
BlinkLoop:
dec R16 //0A 95
brne BlinkLoop //F1 F7
dec R17 //1A 95
brne BlinkLoop //E1 F7
dec R18 //2A 95
out 0x02,R18 //22 B9 -- PORTB
rjmp BlinkLoop //F9 CF
Ideal Version (todo)
Take Geniune AtTiny10 project .hex file
include as some sort of .DB
(correct reg definitions)
(correct avr core rules)
Optimal Version (todo)
Compile code in to 2313
use LPM to automatically generate TPI data
(wrong reg defs)
(wrong to allow use of reg 0..15)
Last nights 'cheat' for quick release
WriteCmd1:
rcall JumpToRomStart
ldi ToSend2,0x04
ldi ToSend4,0xE0
rcall WriteArbitaryWord
ldi ToSend2,0x01
ldi ToSend4,0xB9
rcall WriteArbitaryWord
....
DebugWire used to check 2313 ram content to validate TPI return data.
But, but, ...:
oh come on Lee, getting the chip is enough, as we ALREADY HAVE the development tools. The assembler is the same as we already use. AVR Studio/simulator2 supports the tiny10, and the stk600 is said to support the programming mode. So Given that, it would only take a couple of minutes to get a "blinky" program running on a real chip. I don't see how doing that makes it any more real than having the chip itself.If you wish to test the tools, you can do so now. (less the TPI programming interface of the STK600)
Then why did you need to go through those gyrations? :twisted:
Lee
Well, it is $99 less outlay, but the time taken to implement non stk600-tiny10 solution is probably not worth it in most cases.
It is usefull to those still without access to STK600-tiny10, or those too tight to pay the £££ for stk600 base unit.
I personally - probably would have attempted this anyway, as it was a good learning exercise.
The small cost difference isn't the real plus for me. The Size of it is. I have a design that would be a real squeeze for a Tiny25. The Tiny24 is small but I hate dealing with the QFN-20 package. The whole thing, double sided, is about the size of my thumb nail. Including a DirectFET-MX FET.
I'm waiting for someone to come out with a way to do TPI in system. Otherwise this thing is pretty limited. My program isn't even all that big. Read an ADC, and run PWM.
Hi Jim
I would comment that TPI is just as much "in system" as the usual ISP on the other AVRs
The tricky bit is designing the circuit such that the programming signals dont clash with your runtime IO.
Factor 1:
With only 3+reset, you can't really avoid a clash.
Factor 2:
The relatively weak output of TPI Data (needed by programmer to confirm connectivity and programming) limits its if connected to a strong input
Otherwise, its just avoiding driving your mosfet during reprograming OR tell user to ignore the reaction during isp programming.
Hi JimI would comment that TPI is just as much "in system" as the usual ISP on the other AVRs
The tricky bit is designing the circuit such that the programming signals dont clash with your runtime IO.
Factor 1:
With only 3+reset, you can't really avoid a clash.Factor 2:
The relatively weak output of TPI Data (needed by programmer to confirm connectivity and programming) limits its if connected to a strong inputOtherwise, its just avoiding driving your mosfet during reprograming OR tell user to ignore the reaction during isp programming.
I just got samples last week. I'm dying to get my hands on a reasonanle programmer instead of the STK600+adapter.
I'm still waiting for my samples. I guess that was really samples in 16weeks, and production quantities sometime in the distant future?
Too bad for Atmel, I've actually had a few designs [requiring upwards of 20K units in the next quarter] already flow through that could have used these little buggers, but as I have no samples, they were never designed in. I guess I could have dropped in a larger tiny (at higher cost) but decided instead to leave out the optional functionality that the tiny10 would have provided.
I'm still waiting for my samples. I guess that was really samples in 16weeks, and production quantities sometime in the distant future?Too bad for Atmel, I've actually had a few designs [requiring upwards of 20K units in the next quarter] already flow through that could have used these little buggers, but as I have no samples, they were never designed in. I guess I could have dropped in a larger tiny (at higher cost) but decided instead to leave out the optional functionality that the tiny10 would have provided.
Well this really sucks! here goes another 10K+/a opportunity, though Atmel wins on this one. Doing a re-design for cost savings, and improved reliability/manufactureability on a device based on an tiny25. It's a simple 2 button IR remote, so I only need 3 I/O's, the tiny10 would have been a great fit here to reduce cost even further, but yet again, no samples, so no tiny10 getting a design-in.
MaxMay in https://www.avrfreaks.net/index.p...
We don't usually talk directly to people who buy less than a million dollars worth a year, ...
MaxMay in https://www.avrfreaks.net/index.p...Quote:We don't usually talk directly to people who buy less than a million dollars worth a year, ...
Not sure what you're getting at... That was referring to the crypto-products unit, not necessarily others.
As there are AVR unit employees contributing on this site, I'd reason to say that that statement does not hold for the AVR unit. (Though I'm sure you'll get faster/better service if you were a million dollar customer)
In general the service I get is excellent. It is only when I'm looking for a new product that things seem to fall apart.
From Atmel MCU Support:
me, 04.06.2009 10:58 wrote:What is the maximum TPI programming frequency for ATtiny10.
I could not find any frequency and timing information in the TPI programming section of the ATtiny10 datasheet.
We will get back to you with further information over this.
me, 23.06.2009 13:59 wrote:Sriram Parasuraman, 23.06.2009 13:54 wrote:me, 09.06.2009 12:01 wrote:Is it true ATtiny10 can't be programmed in circuit, but only on the adapter card?
Sorry for the delayed response.
It is true that the device can be programmed only with the adapter card with the help of STK600.Best Regards,
Sriram Parasuraman
Atmel Technical Support Team
How is production ATtiny10's going to programmed then if you can only program it on a STK600 adapter card?
Unfortunately our tools doesn't support this device.
The following vendors provide third party programming support for ATtiny10:
Xeltek www.xeltek.com
System General www.systemgeneral.comSorry for the inconvenience caused.
Best Regards,
Sriram Parasuraman
Atmel Technical Support Team
He also said Atmel has no futher plans of supporting ATtiny10 by other proigrammers or by supporting ISP programming of ATtiny10 with STK600.
So if you want an ISP programmer for ATtiny10 you are out of luck from Atmel and have to buy a 3rd party programmer from Xeltek, System General or another company who might support it in the future - or make your own.
But it's hard to make your own programmer fast and reliable as long as you can't get any specifications for programming speed.
Per a previous post. You should be able to program it In System. I don't see how this chip can only be programmed by the STK600. Atmel just hasn't come up with an ISP device and therefore states that it can only be programmed in an external device. And what are we supposed to do? Develop and use simulation and HOPE the real world works just like the simulation? How often does that happen? This is really a crock. They build a chip with just about Zero support. Way to go Atmel.
I'm waiting for the updated version of the STK600 protocol to be released, that contains the TPI commands. I am planning on making an (open source) In-Circuit TPI programmer that is compatible with the STK600 protocol so it can be used with AVR studio.
I'm waiting for the updated version of the STK600 protocol to be released, that contains the TPI commands. I am planning on making an (open source) In-Circuit TPI programmer that is compatible with the STK600 protocol so it can be used with AVR studio.
Don't hold your breath... the info still isn't online, and I don't have any parts to test with.
Don't hold your breath... the info still isn't online, and I don't have any parts to test with.
I certainly wouldn't refuse a few, if you were willing to part with them :)
I could probably whip up a basic proprietary programmer in a few days... stk-600 implementation will take longer, not counting waiting for an updated protocol spec to be published.
I got some tiny10s but no ATSTK600-ATTINY10 socket card.
I managed to pretend the socket board to the STK600 with some logic chips as described in "AVR600: STK600 Expansion, routing and socket boards". I connected the TINY10 to the ISP headers on the stk600.
Programming works, but only sporadically.
- Does anyone here have experienced something similar or any suggestions?
- I mailed atmel. Here is the answer:
>>>>>>>>>>>>>>>>
Why can the ATTiny10 only programmed ON-BOARD? I tried to programmm the ATTiny10 externally, but it works only sporadically.
Yes, it is possible to program the AVR device ATtiny10 externally through specialy designed tools. There are facts relying on Hardware and protocol considerations and precautions to be taken when designing the system omitting which may lead to unreliability.
Unfortunately Atmel does not currently have a tool for ISP programming of ATtiny10. ATtiny10 is currently only supported by the STK600. STK600 only supports on board programming due to the fact that it uses High-voltage TPI (12V). The programming interface uses the reset pin and I/O pins. An external programmer must be able to control (drive) these pins in the application to be able to program the device.
So it is possible, just a little inconvenient. But it is hard to design a general external programmer to this. So for the time beeing we only support programming on STK600.
<<<<<<<<<<<<<<<<<<<<
What could "There are facts relying on Hardware and protocol considerations and precautions to be taken when designing the system omitting which may lead to unreliability." mean???
- does anyone know of a source for a single Tiny10 socket card. I checked Arrow/Spoerle, Mouser, DigiKey, newark/Farnell, rutronik, ineltek, NuHorizons, MSC, but only got "no availability" or "minimum quantity 25"
i programmed a tiny10 programmer in C using a ATmega128.
Tiny10 firmware is stored in Flash of the mega128.
I used the Codevision AVR C-Compiler.
Enjoy.
[post deleted]
I'd love to integrate the new protocol into my AVRISP-MKII clone firmware for the USB AVRs, but there'd be no way for AVRStudio to use it. If Atmel updates the AVRISP to support it in the protocol, I'd be able to have an AVRStudio compatible clone system running inside of a day or two.
- Dean :twisted:
I think, Atmel won't support the TPI with AVRISP-mkII. In some cases (if RSTDISBL fuse is set) to program the chip, 12V must be applied to /RESET. 12V are not available with AVRISP-mkII.
I'd love to integrate the new protocol into my AVRISP-MKII clone firmware for the USB AVRs, but there'd be no way for AVRStudio to use it. If Atmel updates the AVRISP to support it in the protocol, I'd be able to have an AVRStudio compatible clone system running inside of a day or two.- Dean :twisted:
I made a request to Atmel for the updated STK-600 protocol, which does support TPI. They told me that the document is in the process of being updated, but there is no time line for when it will be available. You and I should talk at some point, as I have been working on a similar effort.
Hi guys,
So I just bought a few of these. I somehow got the impression that they were just ISP programmed. Now I know better. Maybe it was because it's in the list of processors in the AVR910 source. It's in the list but there's nothing else in the code.
According to the datasheet, an AVR910-compatible is electrically capable of programming one, if /RESET is left as-is. So it's possible to update the avr910 code to support them. Nobody appears to have done it yet. I might give it a try.
Wish I had 2 programmers right about now :)
Is it at all possible to get avrstudio to program an attiny10 through an avr910, even if the avr910 has been customised to support it?
Nope, AVR910 is out there. Either get any of the Atmel tools (like an
AVRISPmkII), or have a look at this project:
Note that both the transport used (USART instead of SPI) and the higher level layers are entirely different, so that it would take a significant lot of changes for it to be able to work with AVR910 programmers. You can use my free open source AVRISP-MKII clone firmware as a reference if you like, since it implements all of TPI.
- Dean :twisted:
to get avrstudio to program an attiny10 through an avr910, even if the avr910 has been customised to support it?
The now made Tiny 10 uses a completely different way of programming than the never made old Tiny 10.
Is this confusing enough?
Is this confusing enough?
The now made Tiny 10 ...
Atmel ATTINY10 Distributor Inventory Check Device Distributor Country Stock Date Buy No parts were found. Atmel ATTINY9 Distributor Inventory Check Device Distributor Country Stock Date Buy No parts were found. Atmel ATTINY5 Distributor Inventory Check Device Distributor Country Stock Date Buy No parts were found. Atmel ATTINY4 Distributor Inventory Check Device Distributor Country Stock Date Buy No parts were found.
I don't think an AVR910 is going to do it, ever.
The AT90S2313 code is essentially an ISP bit-banger, and assembles to 1988 bytes. That leaves 60 bytes (at most!) for TPI code.
You could make a version that can *only* program the TPI chips (that's 2 right?) but then you would need a second programmer anyway. Or to program the programmer whenever you wanted to switch between SPI and TPI. Um, no.
So now I am considering making a variation on the AVR910 that's attiny84 (or similar) based and supports both.
The AT90S2313 code is essentially an ISP bit-banger, and assembles to 1988 bytes. That leaves 60 bytes (at most!) for TPI code.
(Since we cannot get our hands on either chip, it does no harm to use a vapour programmer for a vapour chip)
and assembles to 1988 bytes.
Well, xeltek supports ATTINY10 either with an ISP header on any regular single socket programmer or with its first ISP programmer called SuperPro IS01:
Here is a very cheap USB ATTiny10 TPI flasher:
https://www.avrfreaks.net/index.p...
It's an ATTiny25 with some resistors, 2x 3.6V Zener, and a capacitator.
However, if you need 12V (programmed RSTDBL), then you will need an additional transistor and a SIM1-0512 (or similar), of course.
It's a primitive bitbanger, the protocols are implemented on the PC.
Quote:Where do you get that from? I get only 910 bytes ie 44.4% full.and assembles to 1988 bytes.
910 bytes or words?
Bytes as it shows 44.4% full.
Okay, can I have that? :)
Where did you get it?
Here is a very cheap USB ATTiny10 TPI flasher:https://www.avrfreaks.net/index.p...
It's an ATTiny25 with some resistors, 2x 3.6V Zener, and a capacitator.
However, if you need 12V (programmed RSTDBL), then you will need an additional transistor and a SIM1-0512 (or similar), of course.It's a primitive bitbanger, the protocols are implemented on the PC.
I've contacted Olimex and Kee Electronics about modification of their existing "ISP" programmers to support "TPI" protocol. Both companies where interested in the idea. In fact, Kee Electronics said they were going to get started right away. A firmware change to the programmer to support the low level TPI protocol to the DUT wouldn't be very difficult to implement. The high level protocol between the PC and the programmer could remain unchanged.
A discovery process would have to be implemented by the programmer to discover the DUT programming protocol (ISP or TPI). Of course, implementing two seperate low level protocols would require more program memory.But that's not a huge issue either.
Another feature that would be nice on the programmer is HV programming mode. A 5V to 12V charge pump could be added on-board to support the HV mode. This is especially important on the TINY4/5/9/10 micros because Reset will probably get disabled in many applications due to the limited number of I/O pins. Of course the only way to reprogram the device after Reset has been disabled is HV mode.
I can't believe that Atmel isn't interested in updating their ISP programmers to support TPI. IMHO this is a huge mistake. But never fear, the aftermarket is here.
I can't believe that Atmel isn't interested in updating their ISP programmers to support TPI. IMHO this is a huge mistake. But never fear, the aftermarket is here.
Huh? The AVRISP-MKII (and Dragon, JTAG-MKII, etc.) supports TPI and PDI, otherwise I wouldn't have been able to implement it in my clone firmware. No 12V charge pump on the AVRISP-MKII though, so you can't program chips where the fuse has been set.
- Dean :twisted:
Huh? The AVRISP-MKII (and Dragon, JTAG-MKII, etc.) supports TPI and PDI, otherwise I wouldn't have been able to implement it in my clone firmware. No 12V charge pump on the AVRISP-MKII though, so you can't program chips where the fuse has been set.
Well, I must admit that I'm confused. Of course I researched this some before I made the claim. According to the information on the Dragon (Atmel on-line info), it does not support TPI.
http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon.htm
Nor are the ATTINY4/5/9/10 listed as supported devices by the Dragon.
http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon.htm
I know that Atmel doesn't always update their on-line information, and I have a old version of Studio (4.16-628) on my machine. Maybe I will download the latest version and look through the Tools section. Is TPI there for the Dragon ?
Nope. Just downloaded Studio 4.18.684 and can't find TPI support on any Atmel tools with the exception of the STK600 (Searched for keyword "TPI" in Help\AVR Tools User Guide).
Where can I find a mention of support for TPI on other devices other than the STK600 ?
There are 2 service packs after the one you got.
AVRISP mkII User Guide1.6 What's New
Descember 11th, 2009 - AVR Studio 4.18 SP1
Added TPI support for the tiny devices ATtiny10 and ATtiny20.Added support for new devices (see Section 1.5, “Supported Devicesâ€).
Thanks for the tip about the cheaper MAXIM 12V power supply chip!
A tip for the 12V HV TPI programming: the voltage should be applied during the POR phase. Otherwise you will be working against a possible low-level output pin. (The SIM1-0512 cannot handle it. The outcome is ~6V against a low output pin and the chip doesn't reset.)
The low-level RESET can be applied anytime.
I have made a programmer out of a mega328p (I didn't have the parts for the USB version above), and successfully programmed a chip and got it to do something useful.
I feel the need to share what I've leared:
- the data sheet is accurate (when they say you have to wait 16 cycles after pulling reset low they mean it), except that the STS and LDS instructions don't work as for the standard instruction set. They instead work like:
STS: 1010 10a1 rrrr aaaa
LDS: 1010 00a1 rrrr aaaa
where rrrr is the src/dest register and aaaaa is the address of the ram byte, relative to the first byte.
You don't want to know what I had to do to figure that out :)
I'm using linux so I had to modify avra and give it "lds10" and "sts10" instructions, and use these instead of standard sts and lds.
STS and LDS instructions don't work as for the standard instruction set.
Maybe you need to use the correct assembler switch, then it will use the correct STS encoding for the ATTiny4/5/9/10. I'm using the AVR Studio, so I cant tell you what to do with GNU-as.
The STS (16 bit) coding is: 1010 1kkk dddd kkkk
I cant tell you what to do with GNU-as.
I was trying to avoid writing
"I cant tell you what to do with gas." ^^
Hi all,
I thought I'd post in here rather than starting a new topic because I'm having a similar issue only with the ATtiny5.
I'm trying to program an ATtiny5 with the Olimex AVR-ISP-MK2 but can't seem to connect (read the signature) to the ATtiny5. The programmer supports the ATtiny5 but I still suspect the programmer might be at fault. I'm considering buying Atmel's ATAVRISP2 programmer. Links below show that both programmers support the ATtiny5.
My setup is as follows:
-Actual voltage on pins is 5V
-Using the standard TPI interface
-Using Windows XP with Atmel Sudio 6
-Using Olimex AVR-ISP-MK2
-Tried 10k pullup on RESET – changed to 100k (no difference)
Issues:
-Can’t connect to ATtiny5
-Target voltage always reads 3.3V in AVR Studio 4, 5 & Atmel Studio 6
http://store.atmel.com/PartDetai...
https://www.olimex.com/Products/...
ATTINY5-TSHR - 8 BIT, 12 MHZ, 6 PIN SOT-23-6
AVR-ISP-MK2 - ATMEL STK500 V2 AVR PROGRAMMER, OLIMEX
ATAVRISP2 - Atmel ISP Programmer (might buy this)
The Olimex programmer uses my clone firmware. I've tested it and it definetely works on the TINY10, so it should also work fine with the TINY5 (same interface).
The target voltage may be normal depending on what controller they are using; if they selected a ATMEGA*U2 or AT90USB*2 device it doesn't have an internal ADC, so my firmware just fakes the voltage reading to make studio happy.
How exactly are you connecting up the programmer to the chip? Did you use the TPI 6-pin connector, and not the PDI connector?
- Dean :twisted:
Thanks Dean,
I'm connecting the chip using the standard TPI pinout. I've tried it on 2 separate chips but neither seems to work. One chip is in the circuit which has only power, ground, and a 10k pullup on the reset pin. The other chip is free-floating and has just a 10k pullup. In both cases I'm powering the chips using the programmer, not an external supply.
This problem seems to simple to not work. All I need is a 10k pullup on the reset line and power and ground right? How can the chip not connect? Weird.
Dean - you've got me thinking now. I'm wiring to the 6 pin connector on the Olimex programmer which is defined as the PDI / TPI connector. I'm wiring assuming the pinout is TPI, but I see a picture that calls it PDI. I'm guessing my clock and reset are in the wrong positions. The weird thing is that PDI has no RESET pin - am I to assume Olimex put the reset on pin 3? Guess I'll find out shortly.
PIN PDI TPI
1 DATA DATA
2 VTARGET VTARGET
3 CLOCK
4
5 CLOCK RESET
6 GND GND
I'm going to wire it up assuming pin 5 is clock and pin 3 (or 4) is the reset. I'll bet you a dollar it works! Thanks for getting my brain going on the PDI/TPI track :idea:
PDI and TPI are seperate -- according to the user manual the TPI connector is located right next to the USB cable, and not on the other side with the PDI and ISP connectors.
- Dean :twisted:
Wow. I think I owe you a dollar. When reading the overview on page 5 of the datasheet it reads:
"Uses Atmel's 2x5 pin ICSP and 2x3 pin PDI and TPI connector layout"
I took this to mean both TPI and PDI were on the same connector. That one was pretty obvious. :oops: Still no dice on connecting to the tiny5 - I guess there's a chance I killed it. I have a few spares - I'll try to setup a fresh chip and see if it works.
Ok. It was the 10k/100k pullup resistor on the reset line all along.
After updating firmware and removing the pullup I have the ATtiny5 communicating with 2 different programmers. Something I read said to use a 10k to 100k pullup on the reset pin - I typically use a 10k pullup on JTAG, but apparently they're not needed with TPI.
Just thought I'd link on here to my project thread; I wanted to use a tiny10 in a project, and wanted to use the reset pin for something else... so I knocked up a little adapter board to convert a USBasp USB programmer (couple of quid on ebay) to TPI. Once you get it all going it's fast and reliable, but you do seem to have to go through quite a few hoops. With the latest AVRDUDE you can set/clear the fuses and program the flash. OSCAL doesn't seem to work though
https://www.avrfreaks.net/index.p...
