Back
[04:12:22] <LeoNerd> OK now it's getting serious
[04:12:41] <LeoNerd> I'm now looking on Amazon for tiny minifridges to keep my solderpaste in, so as not to mix it up in my normal household fridge
[04:14:54] <LeoNerd> Hrm... prefilled syringe vs. tub of paste + separates. Opinions?
[04:28:26] <specing> fridge for paste?!
[04:34:33] <LeoNerd> You have to keep it cool
[04:34:59] <Tom_itx> tub if you use stencils
[04:35:22] <Tom_itx> yeah, it lasts longer if you do
[04:38:20] <Tom_itx> i just put it in a ziploc bag in the frige
[08:51:18] <_abc_> Hi. Does any version of avrdude support HVSP using a bit banged programmer a la stk200?
[08:51:56] <LeoNerd> I don't believe so. The only HVSP I've seen it manage is stk500
[08:52:04] * LeoNerd is busily building an STK500 clone, in fact :)
[08:52:25] <LeoNerd> I do have an HVSP bitbanger of sorts.. one that outputs to a Bus Pirate.
[08:52:54] <_abc_> avdude docs says it does HVSP on stk500, 600 and dragon
[08:53:02] * LeoNerd nod
[08:53:13] <LeoNerd> Yah but the 600 and Dragon are eeeven more hardware-assisted than 500
[08:53:14] <_abc_> I'm interested in a hvsp embedded solution. Avr burning another avr.
[08:53:25] * LeoNerd has one of those
[08:53:39] <_abc_> I've read the hvsp spec, what's so special besides applying 12V to MCLR?
[08:53:47] <LeoNerd> Not much. It's quite easy
[08:54:03] <_abc_> So technically one could hack it into avrdude? Has anyone done this?
[08:54:07] <LeoNerd> As I said: I've done it initially via Bus Pirate, but currently working on a nicer one
[08:54:08] <LeoNerd> Sure
[08:54:14] <LeoNerd> It's just a matter of attaching hardware
[08:54:28] <LeoNerd> The thing is that so few people *need* that, that it's rare people make the 12V part
[08:54:32] <_abc_> Inside avrdude? As a hack? Yes, one needs an external 12V supply, so what. dcdcs are a dime a dozen.
[08:54:50] <_abc_> LeoNerd: with tiny85 picking up in the duino world, that is due to change soon
[08:54:59] <_abc_> One pin is worth a lot on a device with only 6 gpio
[08:55:03] <LeoNerd> Oh, I didn't use avrdude.. I wrote a compatible drop
[08:55:05] <LeoNerd> dropin
[08:55:19] <LeoNerd> https://metacpan.org/pod/distribution/Device-BusPirate-Chip-AVR_HVSP/bin/avr_hvsp
[08:55:20] <_abc_> I also don't, I am trying to get ready for boat anchored tinys ;)
[08:55:39] <LeoNerd> ^-- HVSP'ing via Bus Pirate
[08:55:41] <_abc_> LeoNerd: is that custom pirate fw or bit banged from host side?
[08:55:54] <LeoNerd> Bitbanged
[08:56:02] <_abc_> Nice. Downloading ;)
[08:56:06] <LeoNerd> Pirate in BBIO mode, use the four GPIO pins
[08:56:08] <_abc_> Inspiration is great.
[08:56:20] <_abc_> I will try to "port" it to C ...
[08:56:23] <LeoNerd> But this code should work fairly easily with any other sort of IO method
[08:56:32] <_abc_> avrg-gcc C to be exact.
[08:56:52] <LeoNerd> Doing it via Bus Pirate is *really* slow because BP is serial controlled at 115200baud, so you need to output entire bytes just to toggle single IO lines
[08:57:08] <_abc_> Sure.
[08:57:17] <_abc_> I'll make it worky.
[08:57:20] <LeoNerd> Since HVSP is an 11-bit serial protocol, you therefore need 22 bytes of UART control to output one byte over HVSP. Burning a single flash byte takes four HVSP bytes.
[08:57:21] <_abc_> (trust me ;)
[08:57:30] <_abc_> Just give me a few 47 hour days and it's done
[08:57:44] <LeoNerd> My stk500 clone is about 300 times faster :)
[08:57:54] <FL4SHK> HOw many HVSP bytes does it take to burn a single FL4SHK byte?
[08:57:57] <_abc_> Assuming none of my dodgy hardware craps out. I use a 2nd machine with stk200 bb if on its parallel port, running headless over ehthernet, to program...
[08:58:22] <LeoNerd> If you have a real hardware parallel port, you should be able to do it a good deal faster yup
[08:58:28] <Thrashbarg> FL4SHK: that sound like a "how many people does it take to screw in a lightbulb" joke lol
[08:58:33] <_abc_> FL4SHK: ? it takes 0, I'll burn you for free? ;) </joke>
[08:58:36] <FL4SHK> :P
[08:59:28] <_abc_> LeoNerd: that's why I'm using it. But it's a machine which was "new" circa 1999 and I am praying to $whoever_matters to make it last a little longer.
[08:59:54] <LeoNerd> Eh.. USB-attached parallel ports aren't hard
[09:00:13] <LeoNerd> Though at that point I'd consider ATmega32U4, CDC, STK500 emulation
[09:00:19] <LeoNerd> Which will be my next plan for v2 of this burner
[09:00:23] <_abc_> Do they work at all? I had a PL2305 (iirc) based one and it did not work well. Takes ages. USB transactions are 4msec or 2msec
[09:00:46] <_abc_> PL2304 maybe. Prolific. The PL2303's Centronics brother.
[09:00:55] <LeoNerd> ATmega32U4 smaller/cheaper/nicer/faster than PL2303 + ATtiny841 + 74xx595 becaues I ran out GPIO pins
[09:01:23] <_abc_> What's the tiny 841?
[09:01:53] <LeoNerd> Basically a much souped-up tiny84. 14 pins, 11(+1) GPIOs. But has two UARTs and a few other nice additions
[09:02:06] <LeoNerd> Basically, if you've ever wanted a tiny84 and been upset that it doesn't have a UART, you want a tiny841.
[09:02:11] <_abc_> Aiee your perl code inlined all operations
[09:02:29] <_abc_> I don't know what an 84 is either. Larger than 8pins?
[09:02:45] <LeoNerd> 14pin
[09:02:56] <_abc_> Ok, I see where that fits in.
[09:03:04] <_abc_> Is there no migration path from 14 pin to 28?
[09:03:07] <LeoNerd> It's pinwise identical to the tiny84. Just has more internal hardware
[09:03:13] <LeoNerd> There is now.. there's new 20pin ATtinys
[09:03:17] <LeoNerd> tiny1634
[09:03:32] <LeoNerd> That one has a couple of *really* fancy tricks
[09:03:33] <_abc_> I see. Shows how green I am. Okay, have to move on, thanks, will be back.
[09:04:04] <LeoNerd> Youknow how in most tinys these days, the CKDIV is an accessible register? On a tiny1634 CKSEL itself is accessible
[09:04:25] <LeoNerd> At *runtime* you can change clock source.. e.g from internal ULP to high-precision external xtal or back again
[09:04:44] <_abc_> I am familiar with pics and avrs which can do that
[09:05:14] <_abc_> my $addr = 0; $addr++ while substr( $got, $addr, 1 ) eq substr( $exp, $addr, 1 ); <- does this pre increment the address ?
[09:05:31] <LeoNerd> Yah... Going from PIC to AVR is always a bit of a disappointment... AVRs just seem to be somewhat behind hardware-wise. E.g. no AVR I know, has remappable peripheral pins
[09:05:41] <LeoNerd> Aside from the REMAP register in tiny841 which *totally does not count*
[09:06:00] <LeoNerd> I don't think you mean pre-increment
[09:06:02] <_abc_> Well I was talking about old pics like 684 and the like
[09:06:13] <_abc_> I mean pre increment before the 1st loop instance
[09:06:23] <LeoNerd> Oh.. no
[09:06:31] <LeoNerd> while loops test their condition before executing the body
[09:06:56] <_abc_> Because that's the way it looks to me. Any good reason for putting that there? addr++ does not look as if it's in the while's body to me, apart from a missing ';' between them?
[09:06:58] <LeoNerd> my $addr = 0; while( substr( $got, $addr, 1 ) eq substr( $exp, $addr, 1 ) ) { $addr++ } # identical
[09:07:21] <LeoNerd> I just find that form a little noiser with all the extra punctuation sitting around
[09:07:41] <_abc_> Ah so you can put the loop body before the test. Right. { ... } while(cond);
[09:08:02] <LeoNerd> Without the braces/parens
[09:08:05] <LeoNerd> It's called a postmodifier
[09:08:19] <_abc_> Did not know the test occurs before the loop body... that's not the way it works in C, right? body is run, then test.
[09:08:24] <LeoNerd> No?
[09:08:28] <_abc_> Afaik, no
[09:08:32] <LeoNerd> while(COND) BODY; in C
[09:08:40] <LeoNerd> condition is still tested before first iteration
[09:08:58] <_abc_> There's do..while, while... and for... in C
[09:09:05] <_abc_> the 1st form does the body before the test
[09:09:12] <LeoNerd> Yeah; that's then a do/while
[09:09:37] <_abc_> So Perl does not have a do..while but lets you swap the body and the while(test) locations? Way to go.
[09:09:45] * _abc_ shudders a bit
[09:09:48] <LeoNerd> ..no?
[09:09:55] <LeoNerd> Perl has a do/while in exactly the same form as C
[09:10:12] <_abc_> If it tests the cond 1st it's not the same
[09:10:18] <LeoNerd> No
[09:10:24] <LeoNerd> The *execution order* is the same as C
[09:10:33] <LeoNerd> while(COND) { BODY } <== identical in C or Perl
[09:10:48] <LeoNerd> Just there's a syntactic shorthand for a while loop whose body is a *single* statement.
[09:10:50] <_abc_> And BODY while(COND) which is what we are on about, is what?
[09:10:56] <LeoNerd> That shortcut is BODY while COND;
[09:11:05] <LeoNerd> This shortcut *still* tests the condition first
[09:11:06] <_abc_> yeuch
[09:11:18] <_abc_> Okay, let's move on.
[09:11:31] <_abc_> Python3 also copied this idiom.
[09:11:32] <LeoNerd> It's largely there for symmetry with other loops, like print for @things;
[09:11:34] <_abc_> Unfortunately
[09:11:46] <LeoNerd> Because that's just a lot less noisy than for (@things) { print; }
[09:12:05] <_abc_> putting the carriage before the horse, with no warning signs is what I would call it!
[09:12:29] <LeoNerd> I find sometimes it helps, to pull "the important thing" up to the front
[09:12:49] <LeoNerd> print for @things; is "obviously" all about printing stuff.. so the print comes first
[09:13:06] <LeoNerd> $addr++ while something here; is "obviously" about incrementing the $addr
[09:13:26] <LeoNerd> Compare to English. "Start at zero, then increment the address while the bytes match"
[09:13:42] <LeoNerd> As opposed to "Start at zero, then while the bytes match, increment the address". It just feels a little more natural
[09:14:18] <_abc_> my $avr = $pirate->mount_chip( "AVR_HVSP" )->get; suggests the real HVSP code is inside $pirate?
[09:14:29] <LeoNerd> Nope
[09:14:38] <_abc_> Then what am I missing
[09:14:43] <LeoNerd> That just looks for a module called Device::BusPirate::Chip::AVR_HVSP, which is where the actual code lives
[09:14:52] <LeoNerd> (because that's what mount_chip does)
[09:15:08] <LeoNerd> https://metacpan.org/pod/Device::BusPirate::Chip::AVR_HVSP
[09:15:47] <LeoNerd> The core of the HVSP driving code is sub _transfer, line 316 there.
[09:16:15] <LeoNerd> Which contains the actual 11-bit serial in/out clocking code. So if you wanted to do that via some other method, that's the bit to adjust
[09:17:04] <LeoNerd> Hehe.. ohyes.. and the pipelining speedup cheat. That gets it about 3 times faster than it would be without.
[09:17:27] <_abc_> What does Future->needs_all( do? The function proper?
[09:17:53] <_abc_> Is that some form of continuation?
[09:17:54] <LeoNerd> Returns a Future that completes once all of its components have
[09:18:24] <_abc_> So that should block because its result is needed to end the function, right?
[09:18:24] <LeoNerd> Ish. It's more the reverse. It's a Future, sometimes called a promise or deferred...
[09:18:34] <LeoNerd> Various languages have various names for the same idea
[09:18:59] <_abc_> ->on_done( is the end condition which is fulfilled only when the entire thing has run, right?
[09:19:33] <LeoNerd> .. yes, ish. I'm not sure here's the place to go into the *entire* concept of Futures, which are entirely orthogonal to AVR HVSP burning :)
[09:19:56] <_abc_> I know. Was asking here and not in #perl due to the context.
[09:20:17] <LeoNerd> I tend to write everything with IO components to it in Futures, because that makes them trivially simple to do concurrently, or asynchronously with other stuff. E.g. some sort of GUI program
[09:20:19] <_abc_> So in brief, you send the entire command relying on pipelining as you say, and read the answer. And that's it.
[09:20:37] <LeoNerd> Yeah. I mostly jsut rely on knowing that the bus pirate won't complain about these GPIO operations
[09:20:45] <_abc_> Okay
[09:20:48] <LeoNerd> It runs faster to keep more bytes flying around in the UART pipeline
[09:20:54] <LeoNerd> If you wait for each one individually it's much slower
[09:21:32] <LeoNerd> But that's all just an optimisation for talking to the bus pirate in the first place. If you were doing that by direct bitfiddling on the parallel port, say, then that wouldn't be needed
[09:21:51] <_abc_> Assume direct bit fiddling in an avr
[09:22:03] * LeoNerd has code for this too ;)
[09:22:13] <_abc_> Okay, I got the way it works. Oh you do? And is it in git?
[09:22:35] <LeoNerd> http://pastie.org/10260256
[09:24:00] <_abc_> Is that code efficient, using the union?
[09:24:11] <_abc_> (space efficient, code space)
[09:24:36] <LeoNerd> Yes; the STK500 protocol has a command where it sends you that 32byte list of programming values
[09:24:46] <_abc_> Ah, that's why
[09:24:48] <LeoNerd> (hint: They're actually always the same for basically any ATtiny chip you're likely to find ;) )
[09:25:04] <LeoNerd> https://metacpan.org/source/PEVANS/Device-BusPirate-Chip-AVR_HVSP-0.03/lib/Device/BusPirate/Chip/AVR_HVSP.pm#L373 <== hardcoded here
[09:26:14] <LeoNerd> you might notice a very similar code structure between this AVR C and Perl programs; I wrote the perl one first while hacking around with the BP, and then this C after
[09:36:03] <_abc_> I see. Okay, thanks. Most parameters are not really used, right? From the 32 passed?
[09:36:15] <LeoNerd> I believe a reasonable number are
[09:36:25] <LeoNerd> But some of them are rare ones like fuse settings
[09:36:36] <_abc_> reasonable = 17 out of 32? ;
[09:36:39] <_abc_> ;)
[09:37:52] <_abc_> I wrote my own bit banged genuine [tm] serial port programmer for avrs (think picprog/siprog etc) many years ago, in tcl (haha I hate Perl). I don't remember any instance where I needed 17 paramters.
[09:37:58] <LeoNerd> every variable named in the .b struct is used somewhere in that code
[09:38:05] <_abc_> Okay.
[09:38:19] <_abc_> If that's the STK500 way to do things, who am I to argue about it.
[09:38:34] <LeoNerd> I make it 31 values
[09:38:48] <LeoNerd> Yeah.. I've no idea why they do it this way. Many of them have the same values as each other, for example
[09:39:05] <LeoNerd> It might just be accounting for historic parts that no longer exist, that used to have different values
[09:39:49] <LeoNerd> The way HVSP works internally is that it's just a pair of shift registers in front of the core AVR HVPP hardware. SII's bits come out on the various control lines and SDI/SDO come out on the data lines
[09:40:19] <LeoNerd> E.g. the thing with the .b.orm byte, that "OR mask". You'll see all that does is toggle the actual HVPP strobe line
[09:42:36] <LeoNerd> Once I've finished this HVSP controller, my next trick will be working on dW :)
[09:42:51] <LeoNerd> Because *obviously* if you have HVSP the thing you next want to do is program DWEN and play around with it
[10:28:42] <LeoNerd> While it's quiet: Anyone here do DIY "home" assembly of PCBs using solder paste? My next board will want that. Seems my options are prefilled syringe, or separates + tub of paste. Opinions?
[11:02:28] <_abc_> LeoNerd:just a second I'll answer that
[11:03:16] <_abc_> LeoNerd: okay so syringe you will have pain working with unless you improvise some means to push the stuff out by hand
[11:03:26] <_abc_> LeoNerd: which means compressed air puffs most of the time
[11:03:46] <_abc_> LeoNerd: They are not really made to be used by hand, you need 2-3kgf to push out the stuff through a tiny needle
[11:04:01] <LeoNerd> Hrmmm
[11:04:06] <_abc_> LeoNerd: The other way is universal stencil, which works but is very tricky to do
[11:04:40] <_abc_> you will smudge what you just did and start over. Someone on #electronics makes you laser cut stencils, 2pcs, for about 10 EUR. They are plastic so you can use them 10 times or so.
[11:04:53] <_abc_> 10x2 = 20 boards, and you can make them last longer.
[11:05:05] <_abc_> Ash shrdlu iirc on #electronics about stencils
[11:05:15] <LeoNerd> I'm not finding anything on "universal stencil"
[11:06:04] <_abc_> You can build (improvise) a syringe actuator coupler relatively easily, it's just a bung which connects the syringe's back to a plastic hose. This is supplied with pulsed air alternating with low vacuum
[11:06:37] * LeoNerd nod
[11:06:49] <_abc_> Air pressure can come from anything including a car tyre near you, inflated on purpose, very little is needed, pressure is important. The vacuum serves to pull back the drop after application else it will drip
[11:06:59] <_abc_> You can live with dripping most of the time
[11:07:10] <DrLuke> Is there any trick involved in compiling code for attiny20 using avr-gcc? It apparently isn't supported by my version of avr-gcc:
http://pastebin.com/ck8eX6qC
[11:07:15] <_abc_> So all you need is an air valve solenoid, car tyre, and a timer
[11:07:45] <LeoNerd> Is ATtiny20 one of those ones that doesn't have memorymapped registers?
[11:07:54] <DrLuke> Uh, no idea
[11:08:05] <DrLuke> I just bought it because it happened to have the right amount of pins for my application
[11:09:10] <_abc_> http://www.aliexpress.com/item-img/3pcs-lot-New-16-in-1-UD-A319-cellphone-reballing-stencils-SMD-IC-template-Tin-plate/1371863721.html LeoNerd universal stencil example. Search google images for universal stencil smd. Do not get the metal kind, you might want to cut it with scissors.
[11:09:31] <DrLuke> It is listed as supported here:
http://www.nongnu.org/avr-libc/user-manual/
[11:09:37] <DrLuke> but it's not listed in my avr-gcc
[11:09:57] <DrLuke> weird
[11:10:04] <LeoNerd> Old version?
[11:10:22] <LeoNerd> _abc_: Hrm. That looks quite small for BGA type things. I'm looking at QFN, plus 0603s which honestly I could do by hand
[11:10:24] <DrLuke> gcc version 4.9.2
[11:10:27] <_abc_> http://www.soldertools.net/plastic-smt-stencils/ LeoNerd plastic is polymide or kapton. The latter is heat resistant.
[11:10:35] <LeoNerd> It's just a QFN and a 6x3.5mm crystal that really *need* this
[11:10:42] <_abc_> LeoNerd: 0603 you need the syringe
[11:10:46] <DrLuke> LeoNerd: It's the newest version available in my repos, and I use arch
[11:10:57] <_abc_> QFN is a right pain to get the stencil right for
[11:11:24] <DrLuke> Build Date: 2014-12-27 14:35 UTC - Seems recent enough
[11:11:27] <_abc_> http://hackaday.com/2012/12/27/diy-smd-stencils-made-with-a-craft-cutter/ LeoNerd of course you could be a gifted jeweller who just so happens to like making small things
[11:11:34] <LeoNerd> hehe
[11:11:44] <LeoNerd> Notsure I want to *hand cut* my stencil
[11:11:58] <LeoNerd> Anyway, I don't think QFN or 0603 really needs a stencil do they? That's what soldermask is for
[11:12:01] <_abc_> Lay off coffee for 3 months, should work ok
[11:12:17] <_abc_> LeoNerd: you need the stencil to dose the paste right for the pads.
[11:12:25] <DrLuke> I do QFN and 0604 by hand
[11:12:26] <LeoNerd> Ah.. hmm
[11:12:31] <DrLuke> I even do 0402 by hand
[11:12:32] <_abc_> LeoNerd: some people flood the 0603 footprint and rely on the mask to do the right thing.
[11:12:49] <_abc_> DrLuke: Are you very very small and live in a nutshell?
[11:12:52] <LeoNerd> Thing is, I would be happy not to bother, and do the 0603s by hand
[11:13:00] <LeoNerd> And then just paste the QFN and crystal
[11:13:01] <DrLuke> _abc_: No, I just use the right techniques
[11:13:23] <DrLuke> You can extend QFN pads to make them easier to solder
[11:13:42] <DrLuke> merely the ground pad can be difficult to solder, but I just use a hot air station for that
[11:13:42] <_abc_> LeoNerd: You know the laser engravers diy from maker/etc? 2 cdrom mechanisms and a laser?
[11:13:45] <LeoNerd> The chip doesn't look ameniable to that
[11:13:51] <LeoNerd> Besides, I'd also miss the thermal pad
[11:14:01] <LeoNerd> Ohcrap, which I forgot to put vias in. .Nooooo
[11:14:21] <DrLuke> The key is to use gel-type flux
[11:14:33] <DrLuke> not the flux-pen stuff, that evaporates too quickly
[11:14:35] <_abc_> LeoNerd: one way to get the thermal pad sorted is to make a large via on the back in the middle of the thermal pad, and fill that with solder (unplated). The solder will flow between the ic back and pad
[11:14:47] <LeoNerd> Mmmm
[11:14:59] <_abc_> DrLuke: I always use the no remove flux for QFN. No way to get it out after the job.
[11:15:02] <_abc_> Same as BGA
[11:15:03] <LeoNerd> well too late for this board, I've already ordered it
[11:15:14] <DrLuke> _abc_: Just flush it with IPA
[11:15:20] <DrLuke> it will get enough out
[11:15:33] <_abc_> LeoNerd: you can drill the vias in the thermal pad before assembly, you actually need just one, then do what I said
[11:15:42] <_abc_> DrLuke: Disagree ;)
[11:15:47] <LeoNerd> Oh.. true. I can drill it :)
[11:15:59] <LeoNerd> Depending on how well my fab does I may have to drill the board anyway
[11:16:05] <_abc_> LeoNerd: just deburr the hole edges on the QFN side very very throughly.
[11:16:12] <LeoNerd> I tried to put in cutouts for reverse-mount LEDs so I'll have to see how that works out
[11:17:17] <_abc_> LeoNerd: you can also photoresist, expose and etch a stencil on copper flashing:
https://www.youtube.com/watch?v=vj8c83QzANw
[11:17:39] <_abc_> That is as hard as making a pcb but it should work okay. Model enthusiasts make small detailed pieces like that all the time.
[11:17:49] <DrLuke> Anybody got an idea about my avr-gcc problems? I'm really bummed out :C
[11:17:55] <DrLuke> and there's nothing on the internet
[11:18:04] <_abc_> DrLuke: you're using a weird part nobody saw before.
[11:18:16] <DrLuke> the Tiny20 is weird?
[11:18:19] <_abc_> DrLuke: Did you even check that the programmer you have supports it?
[11:18:28] <_abc_> I never saw a tiny.
[11:18:31] <_abc_> tiny20
[11:18:34] <DrLuke> it's the official isp MKII
[11:18:43] <_abc_> You check, not I ;)
[11:19:34] <LeoNerd> It appears to be an old 14-pin one
[11:19:38] <LeoNerd> I'd use a tiny84 in that place now
[11:19:51] <DrLuke> It does support it
[11:20:05] <DrLuke> LeoNerd: Maybe, but I already got this one now
[11:20:12] <LeoNerd> Oh. huh. Though the tiny20 does have *real* SPI and I²C
[11:21:17] <DrLuke> The libc page lists it as supported, which is weird
[11:22:41] <DrLuke> https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
[11:22:46] <DrLuke> even this lists it as an option
[11:22:54] <DrLuke> weeeeird
[11:23:18] <LeoNerd> How about showing us how it actually fails? Use some paste site to show output, rather than simply saying "doesn't work"
[11:23:29] <_abc_> Afair you call avr-gcc with the arch and model, some models cover several units
[11:24:06] <DrLuke> LeoNerd:
http://pastebin.com/ck8eX6qC
[11:24:11] <DrLuke> I posted it with my original question :P
[11:24:56] <LeoNerd> Ah. Mm.. well, I'd just try picking something sufficiently close
[11:25:38] <DrLuke> That's not helpful
[11:29:20] <DrLuke> Especially since all devices with that core are missing
[11:29:20] <DrLuke> :/
[11:32:49] <LeoNerd> Hmmm
[11:33:25] <LeoNerd> avr-gcc -std=gnu99 -Wall -Os -DPRIMARY_ppqcue -DF_CPU=1000000 -mmcu=attiny20 ... WFM
[11:33:32] <LeoNerd> so possibly your build is different to mind
[11:34:02] <LeoNerd> http://pastie.org/10260450
[11:39:04] <DrLuke> I'll try an alternative package available
[11:39:07] <DrLuke> maybe it is more recent