Back
[00:10:13] <carabia> these 240x320 lcd + sd holder cheap boards sold on ebay are stupid, there's series resistors on the sd spi line :(
[00:11:30] <carabia> also they only break out 4 pins for 1-bit i/f
[00:11:52] <carabia> i could solder wires straight onto the holder pins for 4-bit... meh
[00:13:03] <carabia> for now i'll use 1-bit and gotta remove the resistors and bridge the pads
[00:52:47] <rue_bed> with one 74595 you can reduce the pin count of a lcd to 3 lines
[00:53:03] <rue_bed> actually, I think I did it with a 74164
[00:53:11] <rue_bed> same diff
[00:56:08] <rue_bed> I wonder if its possable to grind a chip down to the balls to get it off the board
[00:59:03] <Casper> rue_bed: I'ld be concerned about the grinding wheel touching the balls, get stuck on the wheel and tear off the pad
[03:56:21] <WormFood> [13:29:03] <rue_bed> I wonder if its possable to grind a chip down to the balls to get it off the board <-- just use a little torch, to get it off. I've done that before. It's pretty easy. Grinding is risky, because the chip is stronger than the board.
[08:29:49] <merethan> Hi all
[08:37:48] <merethan> avrdude seems to be the standard flashtool these days. However, I'm having some problems with my bootloader and like to swap avrdude out with something else that speaks avr109 to rule out any problems there.
[08:37:54] <merethan> Do any of you know an alternative to avrdude that speaks the avr109 protocol?
[08:38:26] <LeoNerd> avrdude can talk a lot of other protocols too you know :)
[08:38:36] <merethan> Ya but by bootloader can't
[08:38:57] <LeoNerd> Ah
[08:39:31] <merethan> My bootloader is the well known xboot combined with USB CDC from ASF.
[08:42:50] <merethan> About 6% of the devices produced fail to program their appflash over USB. Everything identical (chips even from the same wafer etc.) but 6% of them just fail. Avrdude just quits on them, even though the bootloader replies "ok" after each block of data.
[08:43:53] <merethan> I've been debugging the process by soldering a rs232 line to do debug output on, while the update process runs over USB CDC.
[08:44:03] <merethan> But still I'm completely in the dark what the issue is.
[08:45:39] <merethan> All these freshly produced devices seem 100% identical, yet they aren't.
[08:46:38] <merethan> Now I'm trying to swap bits out in the process chain but have found no replacement for avrdude so far.
[09:09:35] <R0b0t1`> Any difference between USART_TX_vect and USART_UDRE_vect?
[09:10:02] <cehteh> of course, read the datasheet
[09:10:08] <R0b0t1`> Yeah I did
[09:10:29] <R0b0t1`> UDRE seems less useful, as it would trigger on a write to transmit
[09:10:40] <R0b0t1`> otherwise it is exactly the TX vect
[09:10:46] <cehteh> huh
[09:10:56] <R0b0t1`> exactly
[09:11:24] <cehteh> lookin in my code, but i think UDRE is exactly what you want to use
[09:11:45] <R0b0t1`> that's what everyone recommends
[09:11:51] <R0b0t1`> I'll take the hint but it still bugs me
[09:12:25] <cehteh> UDRE triggers when you can put the next byte into the send buffer
[09:12:40] <cehteh> transmission may be still in progress then (stop bits etc)
[09:15:46] <cehteh> tx complete triggers when the complete frame got transmitted and possibly going idle, thats sometimes use for special tricks extending the serial protocoll, switching io lines or such
[09:16:03] <R0b0t1`> ah right
[09:16:37] <cehteh> when you want to send out data as fast as possible you do that from UDRE
[09:16:54] <R0b0t1`> that was really helpful, hard to link that part with everybody using it
[09:17:31] * cehteh thought that was oblivious from reading the datasheet
[09:18:46] <merethan> (Do any of you know an alternative to avrdude that speaks the avr109 protocol?)
[09:21:54] <cehteh> merethan: i think you should debug your hardware/code more, somehow i have doubts its related to avrdude
[09:22:15] <cehteh> there are some other, sometimes ad hoc tools for bootloaders
[09:22:27] <merethan> I've gone to great lengths in that respect.
[09:22:39] <cehteh> still didnt hit the spot
[09:23:00] <cehteh> you have a logic analyzer to figure out whats going on?
[09:23:04] <merethan> The dfu-bootloader from Atmel together with FLIP works.
[09:24:00] <cehteh> did you try dfu-util?
[09:24:05] <cehteh> whats FLIP?
[09:24:42] <merethan> a dfu tool from atmel.
[09:25:06] <merethan> I'd rather use dfu-util though, if I had a linux box at hand.
[09:25:21] <merethan> FLIP is horribly b0rked.
[09:26:40] <merethan> I've also debugged my own code (xboot with a few tweaks to make it work with ASF's USB-CDC) by soldering a physical second rs232 line to a device and sending out chars as debugging. (You see, break points and debugging over pdi halts the USB code too.)
[09:30:09] <merethan> Since flashing using this dfu-bootloader works, hardware is somewhat ruled out.
[09:34:22] <cehteh> possibly some timing issues on the edge .. where different implementations handle the timing slightly diffrently
[09:37:10] <merethan> If so, this timing issue must be a very tight one, since it works on 94% of the chips but not on 6% of them. Yet they are from the same wafer.
[09:37:52] <LeoNerd> What are you using as a clock source?
[09:41:07] <merethan> The 32Mhz. source directly to the mcu itself (x256a3bu) and the PPL osc with some settings to make it output 48Mhz. to USB.
[09:42:09] <cehteh> its always the same 6% chips where it fails?
[09:42:23] <cehteh> would be a start to figure out whats different there
[09:42:28] <LeoNerd> Ah.. the onboard osc. may not be that accurate
[09:42:50] <LeoNerd> I know at least with ATmegas, the internal RC osc. generally isn't good enough to use as a UART clock without trimming it
[09:43:30] <cehteh> yes, it works when you can sync it, but leaving it untouched it master of desaster
[09:43:53] <merethan> cehteh: Yes the problematic ones stay problematic and those without issues continue to work.
[09:44:43] <cehteh> never used xmegas, but i expect it to be similar there
[09:44:48] <merethan> Me nor the Atmel support could figure out a difference. Same wafer, just the location differs.
[09:45:03] <cehteh> can you measure the frequency?
[09:46:44] <cehteh> well if you are working with atmel and ordered custom things from a wafer, this is prolly beyond what IRC support can handle :D .. at least i feel a bit incompetent, except for cases where you overseen something really stupid (linke not calibrating the clock)
[09:47:18] <cehteh> also test if a bigger descpupling cap at the input helps
[09:47:58] <_ami_> is there any guide available on how to connect CH340g to AVR MCU? i don't find it any on googling?
[09:48:08] <LeoNerd> It's a USB-UART bridge
[09:48:22] <LeoNerd> So presumably, cross-connect the TX/RX pins and give it power and USB and stuff
[09:48:35] <LeoNerd> I don't know the G variant, but the T variant at least wants a 12MHz xtal/ceramic
[09:49:18] <_ami_> LeoNerd: ah, bummer. i want my usb device to small.
[09:50:25] <cehteh> xtals can be very small
[09:50:37] <LeoNerd> The smallest USB-UART bridge I know of is the SOIC8 sized PL2303SA
[09:50:42] <LeoNerd> I've had much success with that
[09:50:54] <cehteh> if you want it really small then use a AVR with usb on board
[09:50:57] <LeoNerd> It only does TX/RX, no handshaking. So critically, no DTR making it useless for "Arduino" programming
[09:51:00] <LeoNerd> Also that :)
[09:51:12] <cehteh> needs still a xtal
[09:51:21] <_ami_> http://fobit.blogspot.in/2014/11/ch340g-in-eagle.html - got a good link which describes little abt this chip. :)
[09:51:37] <LeoNerd> Andyes; if you're talking UART to the AVR chip you'll typically want another xtal on the AVR
[09:51:49] <_ami_> yeah :/
[09:51:55] <LeoNerd> But crystals can be small.. I've become a fan of the Murata CSTCE series lately
[09:52:10] <LeoNerd> Tiiiiiiiiiiny little things; they're the ones used on an Arduino Nano
[09:52:25] <cehteh> yes i was thinking of those
[09:52:35] <cehteh> but really .. use a mega with usb on board
[09:52:37] <LeoNerd> So small there's no space on the casing to label the frequency
[09:52:39] <_ami_> LeoNerd: yeah, its tiny.. i just looked at my nano :)
[09:52:49] <LeoNerd> which screws me right up when I have a 12M0 and a 16M0 to put on the same board ;)
[09:52:50] <cehteh> needs 2 xtals iirc ,, but still much smaller
[09:53:34] <LeoNerd> The PL2303SA doesn't need a crystal; it has an onboard PLL that syncs to the incoming USB clock
[09:53:43] <LeoNerd> But then you still need a crystal in the AVR
[09:53:51] <_ami_> cehteh: attiny85 internal oscillator calibrated to 16.5 Mhz is not reliable?
[09:54:11] <_ami_> i heard its not reliable on long run?
[09:54:39] <cehteh> ah you use a tiny. then why dont you use vusb? .. i mean yes it has issues, but if you can proof it to be working it might be good enough
[09:54:54] <LeoNerd> Ugh *shudder*
[09:55:05] <cehteh> of course you need to calibrate the osc to usb
[09:55:15] <cehteh> depends on the usage
[09:55:27] <_ami_> cehteh: LeoNerd: vusb is not good for my case. i need to sample a data for more than 50 ms.
[09:55:40] <cehteh> then doint use a tiny
[09:55:48] <_ami_> usbPoll() requires polling on every 50 ms at least
[09:56:01] <cehteh> whats the smallest mega with usb?
[09:56:15] <_ami_> i need a usb talking chip. you guys were correct since 1st day :)
[09:56:19] <LeoNerd> I expect a 16U2 in its smallest chip form will be physically smaller than the combination of tiny85 + separate USB-CDC bridge
[09:56:28] <cehteh> yes
[09:56:31] <merethan> cehteh: I am not working with custom things from Atmel. Within a batch/production run of devices, there just happened to be Atmel chips originating from the same wafer.
[09:56:43] <_ami_> LeoNerd: never programmed on 16U2
[09:56:52] <merethan> And some of those fail, most do not.
[09:57:01] <cehteh> me neither ,, but somtimes it makes sense to start so :)
[09:57:14] <cehteh> merethan: just debug on :D
[09:57:46] <cehteh> they have tolerances and some drifts, eventually you should find out whats the problem is
[09:57:59] <cehteh> and do you calibrate the clock?
[09:58:07] <merethan> I do have a scope on hand capable of going upto 60Mhz. but I'm not sure my probes are any good in that range.
[09:58:30] <theBear> wafer eh ? from now on i gonna order all my micros from absent minded skinny models, err, wafe'rs, that is <grin>
[09:58:32] <merethan> cehteh: You mean instructing the chip to self-calibrate?
[09:58:33] <LeoNerd> Have the chip output some divided frequency on a PWM pin maybe?
[09:58:43] <cehteh> merethan: no your code
[09:58:48] <LeoNerd> E.g. if you were to output a 60:1 ratio on a clock pin, then you should observe 1.000MHz
[09:58:58] <cehteh> merethan: you use the internal RC oscillator?
[09:59:13] <merethan> Yes
[09:59:25] <cehteh> there (dunno the chip you use) is a OSCCAL register to tune it
[09:59:30] <theBear> my scope says 20mhz, but it does a damned fine job of making an entire trigger-synced frame of composite pal look like errm, a synced frame of pal
[09:59:45] <cehteh> so you pick up the the usb clock and sync/calibrate with OSCCAL along that
[10:00:29] <LeoNerd> 16U2 is available in a 5x5mm QFN32 package
[10:00:48] <LeoNerd> That's smaller than the SOIC8 package of the PL2303SA bridge /alone/, ignoring the ATtiny chip
[10:01:01] <cehteh> but beware OSCCAL (on tiny and megas) is somewhat coarse, just figure out the best OSCCAL value and dont expect it to be perfect, neither calibrate it too often, that only results in jitter
[10:01:48] <LeoNerd> BTW on a vague topic drift: does anyone know the physical mechanism behind how OSCCAL works? Is it a bending cap bank?
[10:01:55] <cehteh> and you *have* to do that to get a usable clock frequency for serial and usb .. i am more surprised that it works on 94% of the chips if you didnt do that
[10:02:21] <LeoNerd> Eh; my 'tiny85 came with a good enough OSCCAL trimming to work as a 9600baud UART
[10:02:27] <cehteh> you are just lucky then
[10:02:30] <LeoNerd> I attempted to tune it and found that the best offset was... +0 ;)
[10:02:42] <cehteh> LeoNerd: yes but usb is more critical
[10:02:51] <LeoNerd> But then I am talking a super-slow rate of 9600baud with a software UART implementation
[10:02:56] * LeoNerd considers self-correcting code
[10:03:02] <cehteh> speed doesnt matter much
[10:03:20] <cehteh> because a 5% error is 5% .. on 1200 baud and on 115200 baud
[10:03:24] <LeoNerd> True...
[10:03:50] <LeoNerd> What I might do is leave the edge-detector enabled, and use that to nudge the timer value if it fires close to but not exactly at the expected time
[10:03:58] <cehteh> i added a api for clock syncing some time ago to mµos
[10:04:24] <cehteh> LeoNerd: be careful .. i tried to be overly smart and failed, too much jitter
[10:04:32] <LeoNerd> Mm.. true
[10:04:36] <cehteh> very simple code works better
[10:04:39] <LeoNerd> It works currently; perhaps I should leave it alone
[10:04:49] <cehteh> have a deadband and allow it for *some* drift
[10:04:53] <LeoNerd> I just have a UART-attached PWM controller. It's a really simple single channel lamp board
[10:05:03] <LeoNerd> It doesn't need to be overly fancy
[10:05:19] <cehteh> only very slowly following the drift and correct like +/-1 per many seconds or so
[10:05:25] * LeoNerd nod
[10:05:56] <cehteh> actually i have this deadband definition and it only corrects when it falls out of the deadband
[10:06:25] <LeoNerd> _ami_: anyway; the 16U2 has prettymuch everything the tiny85 has, and several more things.. so you should be able to migrate your application without any particular problems
[10:06:29] <cehteh> maybe some slowly integral controller might be better inf future .. but needs to be very slow
[10:06:37] <LeoNerd> ... ohwait. No, it lacks an ADC
[10:06:55] <cehteh> LeoNerd: sans the PLL and gain amp or?
[10:07:01] <LeoNerd> The 16U4 has an ADC
[10:07:03] <cehteh> no adc at all?
[10:07:05] <LeoNerd> Nop
[10:07:11] <LeoNerd> It has an anacomp, but no ADC
[10:07:24] <LeoNerd> That's fairly typical of a lot of tiny chips actually as well
[10:07:43] <LeoNerd> Huh.. no I²C unit either
[10:07:49] <cehteh> haha
[10:07:52] <LeoNerd> Wow, this is barely a mega chip at all :(
[10:08:02] <cehteh> atmini :)
[10:08:27] <cehteh> well if it does the job, hah moment he saied something about sampling
[10:08:28] <LeoNerd> One UART, one SPI, two(two?!!) timers... one anacomp, some GPIOs.
[10:09:09] <LeoNerd> Still, not quite as interrupt-starved as the 16U4
[10:09:59] <LeoNerd> Maybe Atmel are just really conservative; I generally haven't seen a USB-enabled AT* chip that has a decent set of other peripherals
[10:10:22] <LeoNerd> As compared to the tiny841 and the mega328PB; which while they lack USB, are generally well provisioned otherwise
[10:11:50] <theBear> 32u4 from memory has a pretty full set of "normal" avr8 peripherals, 2? hwuarts, at least async simul. at least a port of internal multiplexey a-d inputs/"channels" 3 counters, 2of full featured, etc etc
[10:12:06] <LeoNerd> The 32U4 is massively lacking in interrupt ability, though
[10:12:14] <merethan> There's this one thing that bugs me about this frequency thing: When I flash the appcode to the device using pdi, USB works just fine for the appcode, also on the failing devices. This despite the fact both the bootloader and appcode use ASF's USB-CDC code and tune the oscillators the same way.
[10:12:29] <LeoNerd> The four "proper" hardware interrupt lines are muxed onto the UART and the I²C module pins - surely the one place where you'd most likely want to use them with
[10:12:46] <LeoNerd> Most I²C modules/sensors will have an interrupt output line. If you're using I²C - bang; you're two interrupts down.
[10:12:59] <LeoNerd> Using I²C and UART? OK now all four of those main interrupt lines are gone
[10:13:11] <LeoNerd> But that's OK - PORTD is the (one and only) port with PCINT ability. You could use those
[10:13:28] <LeoNerd> Oh except that the SPI module is muxed onto that port. So that's another 3 or 4 pins you can't use interrupts with if you're using SPI
[10:13:30] <_ami_> cehteh LeoNerd: thanks
[10:17:08] <rain1> hello
[10:17:27] <rain1> im trying to use a teensy to program an atmega
[10:39:06] <theBear> wowee ! i hope that teensy had its weet-a-bix
[10:39:21] <LeoNerd> Yes. I was waiting for the actual question/problem
[10:39:28] <LeoNerd> It's usually around now I declare "cool story bro"
[10:41:34] <theBear> heh, i just hope the little guy has the marbles to punch data into a big mega like that, you know, the stones, cahones, the OTHER hidden family jewel stash, the other-other white meat, meat-for-vegetarians, the old gluten-free organic 2 fruit/1 veg combo
[10:42:34] <theBear> it'll be like one of them rocky movies, maybe the one with that massive-ass russian dude about 3' taller AND wider than old sly, talk about yer hollywood magic and david/goliath ripoffs
[10:43:12] <rain1> I got this error: avrdude: Expected signature for ATmega328P is 1E 95 0F
[10:44:23] <LeoNerd> That sounds like the expected sig
[10:52:38] <merethan> You specified the wrong partno rain1.
[10:53:19] <merethan> There's some force option in avrdude to always pass the check btw. Might be useful if the test keeps failing despite having set the right partno.
[10:53:47] <rain1> I think i have the right part though
[10:54:02] <rain1> I'll try to force it and see what happens
[10:54:24] <LeoNerd> Be careful with that ;)
[10:56:07] <merethan> rain1: Don't be lazy.
[10:56:19] <rain1> what should I do merethan?
[10:56:35] <merethan> Check again what chip you have.
[10:56:36] <rain1> I thought you suggested force
[10:56:46] <merethan> Force is last resort.
[10:56:56] <rain1> my part has written on it ATMEGA328P-PU
[10:57:30] <LeoNerd> What -actual- signature did you receive?
[10:57:42] <LeoNerd> We know what the expected value was; what was the real value?
[10:57:53] <LeoNerd> I.e. if it was all-bits-zero or all-bits-one I would strongly suggest the programmer isn't working :)
[10:57:59] <LeoNerd> If it's totally random noise; again.
[10:58:10] <LeoNerd> If it's one or two values off, I might suspect that the chip or the database value was wrong
[11:01:11] <merethan> ATMEGA328P-PU is not in avrdude.conf, ATMEGA328P however is: m328p. Might also be an "uncompatino".
[11:01:49] <LeoNerd> The -PU part of the name relates to the packaging
[11:01:56] <LeoNerd> The plastic case it comes in. It's the same silicon wafer inside
[11:03:31] <merethan> My conf also says signature = 0x1e 0x95 0x0F
[11:03:43] <rain1> yeah i found how to get the avr dude output.. it's all 00 and then all FF
[11:03:58] <rain1> I've double checked my circuit, i think it's correct
[11:04:17] <rain1> maybe it's not going to work well on a breadboard, or I damaged the chip when pushing it in
[11:04:25] <LeoNerd> Or loose connection?
[11:04:35] <LeoNerd> In any case; it sounds like just forcing around the sig check won't help.
[12:27:41] <merethan> Guys/gals, tnx for help!
[12:28:00] <merethan> It likely was the int osc.
[12:29:51] <merethan> I found out that Atmel released some errata some time ago that DFLL may not work if not enabled on both the 32Mhz and 2Mhz int. oscillators with both oscs enabled. (Regardless of whether you use them both or not.)
[12:31:11] <merethan> Even though I only use the 32Mhz. (and 32.768khz for DFLL), enabling the 2Mhz. osc and DFLL on it did fix the issue.
[16:38:48] <LeoNerd> Well, boo. Stencil+pasted a 328PB in QFP32 package onto a board, and three separate pairs of pins have ended up bridged
[16:39:00] <LeoNerd> Chances of my being able to fix that up with a fine iron tip without lifting the entire chip?
[16:39:55] <bss36504> Should be possible
[16:40:07] <bss36504> Use flux :)
[16:40:25] <bss36504> As long as you didn't bridge to a thermal pad you should be ok
[16:50:09] * LeoNerd further wonders if a glass of wine will help this process
[16:51:15] <inkjetunito> how do you guys manufacture the boards? or do you simply order them?
[16:52:07] <LeoNerd> oshpark
[16:52:22] <LeoNerd> Except occasional dirtypcbs when I need them cheap and numerous and I don't care that the silkscreen doesn't look as good
[16:52:30] <LeoNerd> Any board I sell comes from oshpark
[16:58:03] <inkjetunito> i see
[16:59:25] <inkjetunito> :o a glasses-free 3d display
[16:59:42] <inkjetunito> wrong channel, too
[17:41:32] <Tom_itx> LeoNerd, it's pretty easy to fix actually
[17:41:42] <LeoNerd> Yup... I eventually managed it
[17:41:57] <LeoNerd> Just had to drag the solder out away from the chip and eventually the bridges broke
[17:42:02] <Tom_itx> actually you can put more solder on it and suck it all up with a wick
[17:42:06] <LeoNerd> So now I have three finished and ready mega328PB breakouts to sell :)
[17:42:14] <LeoNerd> Ah I tried that; it didn't want to play ball
[17:42:21] <Tom_itx> more flux
[17:42:36] <Tom_itx> i've done hundreds that way
[17:43:25] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/new_batch/USB_chips.jpg
[17:43:27] <Tom_itx> literally
[17:43:33] <LeoNerd> Hrm.. notsure if I have any actual loose flux
[17:43:43] <Tom_itx> get yourself a flux pen
[17:43:46] <LeoNerd> Oh hah.. those trays
[17:43:57] <LeoNerd> I ordered 3 of this chip. *3*. And they came from farnell in one of those trays
[17:44:02] <Tom_itx> they work great for smt
[17:44:04] <LeoNerd> Huuuuge great box
[17:44:55] <Tom_itx> bridging pins doesn't affect my day at all
[17:45:18] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/atmega32u4/atmega32u4_1.jpg
[17:45:33] <Tom_itx> unbridging a couple of those was a bit tougher but still got it
[17:45:44] <LeoNerd> Mmm.. QFN. I might have to swap to those
[17:45:46] <LeoNerd> smaller board
[17:45:54] <LeoNerd> My board is currently wider than a Nano :(
[17:46:08] <Tom_itx> if you plan to hand solder those, increase the pad length so you can get an iron tip on the pad
[17:46:13] <Tom_itx> it will help
[17:46:22] <LeoNerd> stencil + paste
[17:46:29] <Tom_itx> all that was hand soldered btw
[17:46:40] <Tom_itx> i use stencils too
[17:46:54] <Tom_itx> the kapton kind?
[17:47:19] <LeoNerd> Yah. oshstencil
[17:47:23] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/Stencils/stencils.jpg
[17:47:31] <Tom_itx> i used another guy that was great
[17:47:39] <LeoNerd> They won't last that long I'm sure; but hopefully long enough to sell enough to convince me it's worth doing more :)
[17:48:12] <Tom_itx> http://ohararp.com/stencils/
[17:48:17] <Tom_itx> try him sometime
[17:48:23] <Tom_itx> they last
[17:48:28] <Tom_itx> if you take care of em
[17:48:57] <LeoNerd> Oh if these break I'll get myself some oshpark steel ones for this board.
[17:49:00] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/Stencils/stencil_form3.jpg
[17:49:08] <Tom_itx> i made a form from plexiglass to hold the boards
[17:49:22] <Tom_itx> then just flip the stencil over them after tape alighing the edge
[17:49:45] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/Stencils/stencil_form1.jpg
[17:50:02] <Chillum> nice jig
[17:50:03] <Tom_itx> the divit is to pop the board out easy
[17:50:41] <Chillum> jigs are cool
[17:51:40] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/Stencils/stencil_form4.jpg
[17:51:50] <Tom_itx> i just leave them taped to the plexi so they stay aligned
[17:52:06] <Tom_itx> and carefully tape the unused ones out of the way
[17:52:42] <Tom_itx> use vinal packing tape
[17:53:30] <Tom_itx> LeoNerd, i'd continue using the kapton
[17:53:36] <Tom_itx> it will last longer than you think
[17:54:03] * LeoNerd nod
[17:54:08] <Tom_itx> the guy i got mine from will let you fill a sheet for the same cost so i doubled up on ones i knew i'd need spares for
[17:54:09] <LeoNerd> Oh.. not gonna stop until it -actually- breaks, sure
[17:54:59] <Tom_itx> gotta run for now
