Back
[03:39:00] <inflex> Any ideas how to get oil out/off electronics ?
[03:39:29] <malinus> the thing you always use for cleaning electronics?
[03:39:30] <inflex> got an iPhone logic board here that seems to have gone for a swim in light machine oil.
[03:39:51] <malinus> isop.alc.
[03:39:52] <inflex> malinus: well, normally I use an alkaline cleaning solution in my ultrasonic tank
[03:43:27] <skroon> hi all
[03:52:09] <Tom_itx> inflex, naptha
[03:52:45] <Tom_itx> or dish soap
[03:53:06] <Tom_itx> then iso
[03:53:10] <Tom_itx> to dry it
[03:54:33] <inflex> Such a joyous mess.
[03:54:45] <inflex> Still, a lot less traumatic than the urine drenched one I had to clean up last week
[07:02:52] <ionte> hi. i have a very strange problem...
[07:04:11] <ionte> i'm using AVRISP mkII two program ATmega328P. sometimes, quite often, the AVRISP mkII starts flashing red. It does not help to toggle power on the board or disconnect the AVRISP from my computer etc. Then after a while it starts working again, for a while.
[07:05:54] <ionte> avrdude says the cable might be connected in reverse, but it is not (and also, then it would *never* work), but i tried to reverse it. after reversing it, it stopped blinking red, but i could of course not program the mcu. when setting it right again, i was now able to upload the program successfully.
[07:07:05] <ionte> and another strange thing is that i have the same problem with two different AVRISP:s. i've tried on OSX as well as Linux (on another computer). and i've tried with, so far, four different boards, designed by two different persons.
[07:07:22] <ionte> miso/mosi/sck goes straight to the ISP. reset has a pull up of 4k7 ohm.
[07:07:25] <ionte> arrrgghhh!
[07:07:49] <ionte> any ideas?
[11:55:37] <mark4> so the xmega has two types of timer counters and on my device PORTE has a timer counter interrupt but i cannot see anything in the documentatioin telling me if its a type 2 timer counter or not
[11:55:43] <mark4> anyone just happen to know?
[11:56:24] <mark4> ive looked under the section for io ports, ive looked under the section for timer counters and i have looked under the section for timer counters type 2.
[11:56:41] <mark4> nothing tells me what TYPE of timer counter interrupt is associated with port e
[12:01:50] <mark4> crap its worse than i thought, port E has a time counter and a timer counter type 2 interrupt
[12:40:34] <silbo> jo, some motor experts, if I reduce duty cycle is the motor peak current also reduced ?
[12:40:50] <silbo> in other words, does the motor peak current reduce when starting it more slowly
[12:47:41] <silbo> ok seems it's true
[14:45:09] <malinus> sil
[14:45:12] <malinus> rip silbo
[14:58:16] <N1njaneer> New pick and place needs to get here sooner :D
[14:58:40] <Tom_itx> you're just antsy to get your gruby paws on it
[14:59:40] <N1njaneer> Tom_itx: I agree completely. That and we won't ever have to touch a Quad again.
[15:00:05] <malinus> a quad?
[15:00:13] <Tom_itx> qfp?
[15:00:23] <Tom_itx> qfn
[15:00:32] <Tom_itx> 4 wheeler?
[15:00:36] <N1njaneer> Quad-brand pick and place stuff :)
[15:00:45] <N1njaneer> Have three, will all go away :)
[15:00:55] <Tom_itx> send me one
[15:00:56] <malinus> N1njaneer: in your own house?
[15:01:08] <malinus> Or at work
[15:01:32] <Tom_itx> it's mounted in his kitchen
[15:01:38] <Tom_itx> doubles as a dishwasher
[15:01:47] <N1njaneer> malinus: The house used to be the office, now it's seperate :)
[15:02:22] <N1njaneer> Tom_itx: They only weigh about 3000 lbs each - I wonder how many US Stamps I'd have to stick on.
[15:02:37] <Tom_itx> about another 3000lbs worth
[15:02:53] <N1njaneer> Damn, then we have the same problem that rocket engineers have. :D
[15:04:46] <N1njaneer> The Quads were a nice step up from the original Manncorp machine, but just getting too old for running the kinds of parts we need to do in production. They work, but need too much attending.
[15:07:01] <N1njaneer> New one will handle 01005's just fine but the stencil printer won't!
[15:08:32] <N1njaneer> It's stupid how much good stencil printers cost, but if you don't get good prints the rest of the process is majorly downhill from there. :(
[15:10:43] <N1njaneer> Anyhow, I degress.
[15:22:52] <awozniak> why does twi_megarf.[ch] in the asf have unused "volatile void *twi" parameters in some of their functions?
[15:23:15] <N1njaneer> Probably because someone never cleaned them up? :)
[16:09:25] <mark4> trying to put some code in the boot sector of a 256a3bu. am looking at the listing file and no matter where i put the text the VMA and LMA are always 000000
[16:10:07] <mark4> also, when i set .org for these devices do i double the address bcause the gnu tools are too stupid to understand 16 bit cell sizes?
[16:10:25] <mark4> i.e i want my code in the boot sector at 0x200000 so i set .org 0x0400000 ?
[17:41:17] <awozniak> mark4: it might be instructional too look at how xboot does it.
https://code.google.com/p/avr-xboot/
[18:21:06] <mark4> awozniak, ty!
[22:40:27] <kline> does anyone know where the docs are for the ISR prologue/epilogue ? for some reason i think i know that entering and exiting an interrupt takes 8 cycles each but i dont know why and i cant find the docs to back it up
[22:45:09] <Tom_itx> would it be in the asm manual?
[22:45:31] <kline> i dont know
[22:45:59] <kline> i wouldnt think so since theyre generated by the toolchain and you dont have to do them
[22:48:23] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/pdf/atmel/ASM_User_guide.pdf
[22:48:45] <N1njaneer> kline: The only overhead is the hardware execution of the ISR, and the overhead of the return operation. Any pre or post-amble is toolchain dependent based on what registers need to get saved. If your ISR only does something like toggle an i/o or something that needs no registers, you don't have any additional overhead.
[22:49:11] <N1njaneer> The datasheet details all of that, as well as some further info in the document that Tom linked :)
[22:50:31] <kline> sorry, i should clarify that im looking for the prologues/epilogues that avr-gcc generates
[22:50:59] <N1njaneer> That's I'm not sure on. Honestly you can glean a lot from just writing some code and looking at the .lss file output :)
[22:51:33] <kline> yeah, its just really bugging me. im /sure/ i read it somewhere!
[22:51:41] <N1njaneer> A bit more empirical in approach, but just as valid. :)
[22:53:06] <N1njaneer> There's a certain clock cycle overhead to servicing the ISR for sure -- that's detailed in the device datasheets. Then there's a certain number of clock cycles taken by the return at the end, but those two operations can be narrowed to Atmel's documentation. It might well be a total of eight, as I seem to remember what you're talking about.
[22:53:40] <Casper> kline: the datasheet will not cover it fully
[22:53:56] <N1njaneer> gcc will add to that overhead with push/pops for register savings, but there shouldn't be anything else beyond that which would introduce a fixed overhead from gcc.
[22:54:07] <Casper> I think it take 3 cycles for the jump in and out, the rest is due to C that save some registers
[22:54:31] <Casper> you can check it with the pseudo asm output if your makefile generate it
[22:55:12] <N1njaneer> "reti" (return interrupt) takes 5 cycles alone
[22:55:18] <Casper> really?
[22:55:31] <Casper> I tought reti took 3 or 4.... you sure about the 5 cycles???
[22:55:31] <N1njaneer> So if what Casper says with the 3 cycles for the jump in, 3 + 5 = magic 8 number
[22:55:50] <N1njaneer> Casper: Yes, looking at the instruction set right now. I thought it was 3 or 4 as well.
[22:56:16] <N1njaneer> Look at it under "Instruction Set Summary" at the end of any Atmel device datasheet - handy reference :)
[22:56:24] <Casper> yeah
[22:57:52] <N1njaneer> One thing that's cool about ARM is that there's multiple operating modes that have shadow sets of registers, so for instance when running an ISR, a good chunk of the registers are shadowed so it's not necessary to burn time by saving and recalling registers to the stack.
[22:58:47] <N1njaneer> The ISR automatically swaps in to that shadow set, so R0 running under the ISR is a different R0 than the one that the processor just left in your program. So you lop off a huge amount of overhead for quick servicing of ISRs :)
[22:59:44] <N1njaneer> The ISR overhead on Atmel is exactly why for very data intensive applications it's often move efficient to poll than to use ISRs. At least with polling it's a lot easier to absolutely ensure deterministic timing flow to make sure the wrong combination of things can't come along to risk a data underflow, etc :)
[22:59:54] <N1njaneer> on +AVR (not Atmel) -- sorry