Back
[02:12:31] <JOBGG> hey
[02:19:56] <Roklobsta> yeh
[02:40:15] <JOBGG> i'm really struggling with this bit twiddling problem. anybody care to lend a hand?
[02:41:58] <RikusW> there is a tutorial on tom's site (look in topic)
[02:42:39] <JOBGG> not bit twiddling per se. it's more "I can't get this multiplication problem into my head"
[02:43:20] <RikusW> using AVR asm ?
[02:43:40] <JOBGG> kinda. i'm using a tiny, so I've got no hardware multiplier.
[02:44:03] <RikusW> there is Atmel appnotes explaining it
[02:44:19] <JOBGG> yes, shift and add, shift and add.
[02:45:15] <Roklobsta> hmm, url me
[02:45:26] <JOBGG> url me?
[02:46:55] <Roklobsta> link on toms page
[02:50:12] <RikusW> appnote AVR200
[02:50:27] <RikusW> 201 202
[02:51:47] <JOBGG> I actually have a way to do the calculation. I'm trying to optimize it so I won't need additional registers for it.
[02:53:15] <JOBGG> the term is r1 = (byte) r1 x (r2/0xFF), and r2/0xFF would need a float from 0 to 1, or I'd need a word for r1 x r2.
[02:54:09] <JOBGG> since I'm doing software multiplication, I think I can get it working with less, and I was looking for sugesstions.
[02:55:31] <JOBGG> sorry, I think I'm just a little bit slow right now, I'm a little bit sick.
[02:56:16] <RikusW> I haven't actually had the need to multiply in asm yet :) or rather I avoided it :-P
[02:57:03] <JOBGG> its really optimizing the thing because it'll go into an interrupt routine.
[02:57:44] <JOBGG> it's pwm data....oh sheet, I can't even do that with my current setup.
[02:59:09] <JOBGG> I'm getting the data pretty much preformatted.
[03:01:32] <JOBGG> i think the problem just solved itself, best thing I can do is to add waits after a full 8 bit pwm
[03:03:17] <RikusW> simpler is always better
[03:05:10] <JOBGG> sometimes.
[07:06:27] <AllinYourhead> Hi im making a RTC on a ATmega328 and have calculated that i need compare value of 250 with /64 divider to make a millisecond overflowing counter. (250 * 64 * 1000 = 16MHz). Should the timer compare value be 250 or 249 to achieve this? Ive done some testing of both and they both drift of in either direction of a comparing clock (prolly my cheap hardware tolerences causing that inaccuracy but its
[07:06:27] <AllinYourhead> only a temp dev board)
[07:09:36] <specing> you probably don't need "a compare value of 250", but rather "250 steps"
[07:10:31] <specing> and it won't really matter since you want to do calibration anyway
[07:10:56] <specing> like adding a value every 64/128/256/... milliseconds
[07:19:17] <AllinYourhead> isnt that how the compare register of the timer works? i set it to increment the counter every 64th clock cycle, when this counter reaches the threshold set in compare register (249 or 250) it causes an interrupt that increments the variable milliseconds in the program which i can query for clock readout
[07:20:04] <AllinYourhead> called CTC mode and CTC interrupt in datasheet
[07:21:32] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_timers_index.php
[07:21:36] <Tom_itx> Parts 4 & 5
[07:34:30] <AllinYourhead> so 249 it is
[07:35:00] <Tom_itx> AllinYourhead, you could also put a 32.768Khz crystal on timer 2 and save yourself some grief
[07:35:44] <Tom_itx> The clock source for Timer/Counter2 is named clkT2S. clkT2S is by default connected to the main
[07:35:45] <Tom_itx> system I/O clock clkIO. By setting the AS2 bit in ASSR, Timer/Counter2 is asynchronously
[07:35:45] <Tom_itx> clocked from the TOSC1 pin. This enables use of Timer/Counter2 as a Real Time Counter
[07:35:45] <Tom_itx> (RTC). When AS2 is set, pins TOSC1 and TOSC2 are disconnected from Port C. A crystal can
[07:35:45] <Tom_itx> then be connected between the TOSC1 and TOSC2 pins to serve as an independent clock
[07:35:45] <Tom_itx> source for Timer/Counter2. The Oscillator is optimized for use with a 32.768 kHz crystal.
[07:36:42] <AllinYourhead> i already have my 16 Mhz clock at those ports, with your solution i would have to run the system on an internal clock, right?
[07:37:35] <Tom_itx> i'm not sure about that but you may be able to use the rest of the system with your 16Mhz crystal
[07:37:56] <AllinYourhead> XTAL1/2 and TOSC1/2 is same pin on ATmega328p
[07:39:55] <AllinYourhead> initial question was really does the timer increment and then compare in CTC mode or does it compare before increment. Apparantly compares before since 250 steps is 249 in compare value - verified by the example in your link
[07:40:36] <Tom_itx> he would know, he works for atmel
[07:41:05] <twnqx> oops.
[07:41:17] <twnqx> i think i have to go back to some code of mine.
[07:41:18] <AllinYourhead> ye i know, used his examples for many parts of my project :)
[07:42:29] <Tom_itx> later..
[07:45:43] <RikusW> AllinYourhead: remember counting starts at 0 not 1
[07:46:58] <AllinYourhead> ye ofc, but a timer reset sets register to 0x00. Question was then does the CTC mode compare before or after the next increment
[07:47:20] <RikusW> hmm
[07:47:29] <RikusW> never looked at it that closely ;)
[07:47:29] <AllinYourhead> before is the answer
[07:47:37] <AllinYourhead> let me get you an example
[07:48:09] <AllinYourhead> from abcminiuser's guide:
[07:48:10] <AllinYourhead> OCR1A = 15624; // Set CTC compare value to 1Hz at 1MHz AVR clock, with a prescaler of 64
[07:48:22] <AllinYourhead> 15624*64 = 999936
[07:48:32] <AllinYourhead> 15624*64 = 1 000 000
[07:48:44] <AllinYourhead> 15625*64 = 1 000 000 i mean
[08:19:13] * AllinYourhead slaps ravon around a bit with a large trout
[08:33:58] <ambro718> error: template instantiation depth exceeds maximum of 900
[08:34:00] <ambro718> apparently g++ isn't font of my template metaprogramming to generate a lookup table
[08:34:10] <ambro718> *fond
[13:04:06] <megal0maniac> I get the idea that RAM is terribly wasteful of pins...
[13:12:40] <N1njaneer> Depends on the type of RAM - there's SPI and I2C solutions that only need 2-3 pins :)
[13:14:36] <theBear> and while that works fine, you might be looking at a stick of sdram or ddr or something while you think, and they tradeoff pincount for high speed
[13:14:48] <theBear> and single cycleness i suppose
[13:15:52] <megal0maniac> theBear: I'm looking at similar RAM chips. The ones with 12 address lines and 16 data lines
[13:15:53] <bss36504> Does anybody know of a good, easy to follow description of a FAT12 table? I have the ability to program a memory chip at a byte level and I'm trying to verify my controller is working properly.
[13:16:11] <megal0maniac> More specifically, here:
http://xess.com/prods/prod048.php
[13:16:40] <N1njaneer> How much RAM do you need?
[13:18:02] <megal0maniac> I don't, I was just looking at that FPGA board. The flash and RAM can't be used simultaneously due to pin conficts, and the bank-select pins are tied together so you can only use half of the actual RAM.
[13:18:31] <megal0maniac> Which isn't an issue, since it's more than you're likely to ever need on that board, but yeah. I guess it's a speed thing
[13:18:50] <megal0maniac> I really like the XuLA board. The documentation is amazing
[13:21:09] <theBear> megal0maniac, mmm, sounds fairly standard for a normal/parallel ram chip, when you got a 'real' old style or big modern cpu, you got WIDE buses, using maybe 16 to address, err, 4 chips with 11 common lines and another 16 for 16bit stored values is trivial
[13:21:29] <theBear> but on a micro you gotta make tradeoffs, pins are valuable, you gotta decide what deserves them the most :)
[13:21:43] <N1njaneer> Or use a bigger micro that has a lot more pins
[13:22:12] <megal0maniac> Well this is an FPGA, but I get your point :)
[13:22:33] <megal0maniac> OndraSter__ wanted to add RAM to an xmega board, but I think that was SRAM
[13:22:40] <megal0maniac> Using DMA iirc
[13:22:46] <megal0maniac> And LOADS of pins
[13:22:56] <theBear> also in early more primitive days, it's so much easier like that, just setting an address in one command, and reading in a byte or two off a port/address, vs clocking in stuff bit by bit and maybe having to decode, also having to initialise/setup (often) rather than just ram being ram
[13:22:57] <N1njaneer> FPGAs scale up i/o pin counts dramatically, too :)
[13:23:13] <theBear> indeed, i dream of having fpga scale i/o at home one day :)
[13:28:38] <megal0maniac> theBear: What do you think of the board I linked?
[13:29:26] <theBear> i think the other channel is too fast and i missed it :)
[13:29:30] <theBear> 048 ?
[13:29:49] <megal0maniac> That's the one
[13:30:03] <theBear> ok, i look at that, if you tell me what you think of this !
[13:30:08] <megal0maniac> #girlsgonewild ? :)
[13:30:09] <theBear> https://fbcdn-sphotos-g-a.akamaihd.net/hphotos-ak-frc1/705_535750513165662_1935926333_n.jpg
[13:30:35] <megal0maniac> OHGOODLORD
[13:30:46] <megal0maniac> No.
[13:31:00] <theBear> ahh, i think that sounds familiar
[13:31:32] <theBear> hehe, it kinda hurts my head, i got a bad habit of loading links and looking in batches recently, not quite sure where that one came from :)
[13:33:58] <N1njaneer> Board looks nice. I've layed out quite a number of designs with Spartan2/3 series chips. Very easy to work with.
[13:35:06] <N1njaneer> As long as you're not doing super high-speed stuff, differential pairs, or trying to pass radiated emissions testing you're probably good :)
[13:35:22] <N1njaneer> Can't beat the price for a one off
[13:36:26] <megal0maniac> I like the way the PIC kind of, looks after stuff. Like whether or not to load the bitstream from the flash, whether the flash or RAM are enabled etc. And the documentation is amazing. Aside from the manual, he literally wrote a book
[13:36:35] <megal0maniac> Looks like a good place to start :)
[13:37:23] <megal0maniac> N1njaneer: I'm a student who has a collection of AVRs but has never touched an FPGA. Looking to learn
[13:37:47] <N1njaneer> For a configurable board, yes, those are nice things to have managed. The FPGA start-up behavior is governed by the configuration of M0-M3 pins, which are generally hard-wired on a board since you usually won't change modes mid-deployment :)
[13:38:49] <N1njaneer> If you want the absolute best reference book specific to Xilinx stuff I've found yet, look up FPGA Prototyping by VHDL Examples: Xilinx Spartan-3 by Pong P. Chu
[13:39:04] <megal0maniac> Ah, I see. Was wondering how that interfaced
[13:39:06] <N1njaneer> There is also a Verilog version, but I prefer VHDL :)
[13:39:26] <megal0maniac> Ooh, nice. And specific not only to Xilinx, but Spartan-3 as well
[13:40:23] <N1njaneer> When I got started with FPGA stuff about 10 years ago when I graduated college, there was just a random mixed collection of resources out there that you kind of just had to string together and muddle through learning. The VHDL books were specific to VHDL as a language and not specifically for synthesis on an FPGA, etc. Was quite a bit of frustrating!
[13:41:53] <megal0maniac> This is the one I'm looking at now:
http://xess.com/appnotes/FpgasNowWhatBook.pdf
[13:43:23] <N1njaneer> I'd not call that a book, I'd call that a slight primer as to how to power on and test the board. :)
[13:43:55] <megal0maniac> Well, yeah.. :P
[13:44:09] <megal0maniac> Helpful nevertheless. I'm learning stuff
[13:44:13] <soul-d> sighs
[13:44:16] <N1njaneer> If you've never done FPGA stuff before, you'll really want something like Chu's book. He's a professor at CSU who teaches this stuff, so it's very well written from the perspective of someone trying to teach a course on this stuff :)
[13:44:44] <soul-d> ill get my war gear out altera camp here :>
[13:45:05] <N1njaneer> Helps to have a good grasp on things like combinatorial logic, state machines, etc but he goes over most of the basics with that stuff as a refresher as well.
[13:46:30] <N1njaneer> Eh, you use what is easiest for you to use. I have 10 years of Xilinx experience, have used the chips in many designs and have the JTAG debug hardware, etc. So I stick with Xilinx. Altera will do the same, but requires completely relearning a different toolchain, different hardware, and requalifying silicon, schematics, and footprints.
[13:47:16] <soul-d> well yeah that would be best suggestion try both toolchains
[13:47:32] <N1njaneer> The point isn't which ferryboat will get you across the river, it's which is fastest/easiest/least-costly for you to take. And have enough sense to get off it it looks like it's about to sink :)
[13:47:33] <megal0maniac> I'll look out for it, thanks :) Due to buy a bunch of textbooks for this semester in any case
[13:47:35] <soul-d> last time i used quartus it was running fairly well on linux
[13:48:24] <N1njaneer> PIC works as well as AVR for a lot of stuff, but I've been doing AVR for 12 years now and I have absolutely nothing but positive results with both the products as well as amazing low-level support from Atmel.
[13:48:26] <soul-d> there is a textbook out their for student wich is based on quartus 9.2 was pretty new like 2012 ish while 10+ was already out etc etc
[13:48:34] <soul-d> stear clear of that quartus book :P
[13:49:21] <soul-d> it uses depreciated stuff really bad author just wanted some quick cash by reprinting and to much work to do it properly
[13:50:05] <N1njaneer> And with the recent explosion of support that Atmel has given to ARM/AVR on the toolchain side of things, it fills in a huge gap for people needing to get going with this stuff for the first time from a learning and example standpoint. Hardware is awesome, but unless you have familiarity with it, support and documentation can easily make or break your experience with it, and ability to reach your
[13:50:06] <N1njaneer> end-goal
[13:51:24] <N1njaneer> BBL - my ESD vinyl stripping just arrived. Gotta go retrieve it and tack it up on the production floor!
[13:51:48] <soul-d> :)
[13:52:13] <N1njaneer> Good luck to you, megal0maniac! The FPGA stuff is really a lot of fun to get going with. I'd suggest investing in a nice logic analyzer (such as a LOGIC16) to help you debug and explore more efficiently.
[13:52:46] <megal0maniac> I've found that PIC often offers better value for money on some hardware, like the 18F14K50. But the compilers are proprietary and I already have programmers for AVR so I haven't tried :)
[13:53:22] <megal0maniac> N1njaneer: Thanks. I have a LOGIC8 already, but no doubt it will be helpful
[13:54:18] <N1njaneer> Perfect! You're all set to go then!
[13:54:55] <megal0maniac> Not until I actually have an FPGA to learn with :P
[13:55:01] <megal0maniac> But that will come
[13:55:29] <N1njaneer> And yes, there are cheaper solutions than AVR (like TI MPS430 which AVR can't even touch on a price-point) but unless you're in a super-sensitive cost application that needs to shave pennies, go with what is easy first, make it work, then trim down.
[13:56:23] <N1njaneer> Other nice thing about AVR is that many of the devices are just scaled in memory sizes, so you develop on say a '168, then trim it down and see if you can fit it in an '88 or '48 and save some money on the final result :)
[13:57:01] <megal0maniac> Is that not common practice with other manufacturers?
[13:57:25] <Roklobsta> N1njaneer: i am working on a bloated AVR RTOS. You need an atmega 5120 for it.
[13:57:37] <N1njaneer> Damn :)
[13:57:52] <N1njaneer> Largest I've used yet is a 2560, and that still had a ton of room to spare left over :)
[13:58:26] <N1njaneer> FAT32 file system, radio com, OLED display, and a lot of dataflow, battery powered device, 8Mhz :)
[14:00:12] <N1njaneer> No RTOS - no overhead for it in this app
[14:00:41] <megal0maniac> I have an atxmega256a3u, but I'm more interested in peripherals and event system and all that. Not size so much
[14:00:59] <megal0maniac> And for the most part, they seem to be cheaper than their atmega counterparts
[14:02:33] <N1njaneer> Depends on the quantity and supplier, too.
[14:03:13] <megal0maniac> True, as always. Nothing I've done has been more than I one-off
[14:03:20] <megal0maniac> *a one-off
[14:03:44] <N1njaneer> Your suppliers will work with you on price when you need to order 10,000+ of something that isn't a resistor :)
[14:10:37] <R0b0t1> When you start thinking about 2560, it tends to make sense to just move onto a cortex
[14:10:58] <megal0maniac> Even my AT32 chip is 128kb
[14:17:03] <megal0maniac> Wow... Downloaded the colossal xilinx suite, and it doesn't have support for anything but the latest and greatest 7 series stuff
[14:26:44] <Tom_itx> heh i did that a while back
[14:27:03] <Tom_itx> you can download older versions
[14:27:17] <theBear> lol
[14:28:01] <Tom_itx> i needed to build some files for a board i have
[14:29:23] <Roklobsta> is there someway to avoid having the avr blurb out a byte of crap on the uart when i start my program?
[14:30:03] <Tom_itx> tell it not to?
[14:30:45] <Roklobsta> ah, thanks Tom_itx
[14:31:00] <megal0maniac> Tom_itx: I have 1mbps DSL :'(
[14:31:02] <Tom_itx> np, always glad to help
[14:31:08] <Roklobsta> actually, youhave a point, i wonder if the tx irq is being fired.
[14:31:19] <Tom_itx> megal0maniac, i got cable and it still took a while
[14:31:29] <megal0maniac> Third-world problems :/
[14:31:51] <Tom_itx> it was some ungodly size... i forget
[14:32:02] <megal0maniac> wget shall run inside a screen until the end of the week. It's just over 5gb
[14:32:20] <megal0maniac> Ah. 5.9gb
[14:33:09] <twnqx> megal0maniac: wtf did you download, you want the full ISE
[14:33:23] <megal0maniac> twnqx: I accidentally got Vivado
[14:48:31] <RikusW> megal0maniac: I downloaded 6GB yesterday ;)
[14:48:54] <megal0maniac> You have a 4mb line at least :P
[14:48:58] <RikusW> in heh
[14:49:06] <RikusW> -in
[14:49:19] <RikusW> not so much today
[14:49:27] <RikusW> torrent finished downloading
[14:49:42] <megal0maniac> I could use University internet. I've gotten around 65mbps, but I have to pay for it :)
[14:49:51] <RikusW> how much ?
[14:49:57] <megal0maniac> And I won't get that speed with an international site
[14:50:03] <RikusW> some uni's charge a lot
[14:50:27] <megal0maniac> Ours isn't so bad. We get R250 credit per month, which I worked out to about 5gb
[14:51:35] <megal0maniac> Hello abcminiuser!
[14:51:45] <abcminiuser> Yahoyhoy
[14:51:55] * abcminiuser just ate enough sushi for three people
[14:52:23] <megal0maniac> My friend did that once and proceeded to throw up into a canal. I learnt from his mistake
[14:53:08] <abcminiuser> This was from a reputable place
[14:53:12] <abcminiuser> Damned good food
[14:53:32] <megal0maniac> So was this. But he had _that_ much
[14:54:09] <megal0maniac> I've decided that all you can eat is not worth it. You end up eating more and more to make it worth it which leaves you feeling uncomfortable, or ripped off
[14:55:05] <megal0maniac> Now I want sushi. Damn you!
[14:55:17] * megal0maniac installs python
[14:58:46] <twnqx> sushi is not made from snakes.
[14:59:02] <megal0maniac> I've had an eel hand-rool though
[14:59:07] <megal0maniac> Pretty close
[14:59:11] <megal0maniac> *roll :)
[14:59:19] <twnqx> also, i have a 3.8kg roastbeef in the fridge :3
[15:27:57] <OndraSter__> snakes food..
[15:28:02] <OndraSter__> TopGear Vietnam anyone? :D
[15:28:13] <OndraSter__> I exactly know how Richard felt
[15:52:36] <twnqx> not that far in yet
[15:52:40] <twnqx> just in the middle of season 6 :P
[15:55:30] <N1njaneer> abc: Hooray sushi!
[15:55:31] <OndraSter__> haha
[15:55:35] <OndraSter__> no idea what season that was
[15:55:38] <OndraSter__> but I saw the special like 4 times
[16:06:08] <N1njaneer> Mmm hummus and shwarma
[16:23:08] <RikusW> N1njaneer: how about some falafel ?
[16:23:16] <N1njaneer> I actually have some of that, too!
[16:23:45] <N1njaneer> Amazing local mediterratian place
[16:24:28] <RikusW> Was a while since I had any, there isn't many shops selling those around here (ZA)
[16:25:41] <N1njaneer> ZA? South Africa?
[16:26:08] <OndraSter__> I like how in ZA you drive on the left since it is part of the UK (was), but you speak Dutch and not English :P
[16:26:58] <RikusW> yes
[16:27:06] <N1njaneer> Wow, nice
[16:27:14] <RikusW> Afrikaans not Dutch :-P
[16:27:32] <RikusW> Though there are a lot of English speaking people here too
[16:28:02] <RikusW> OndraSter__: its you driving on the wrong side of the road :-D
[16:28:29] * N1njaneer mails Rikus some falaffel overnight FedEx, which means it'll get there in a week if customs doesn't eat it
[16:28:39] <RikusW> heh :)
[16:28:44] <OndraSter__> RikusW, I never said anything about wrong side
[16:28:53] <RikusW> N1njaneer: which country are you from ?
[16:28:53] <OndraSter__> :P
[16:29:07] <N1njaneer> USA
[16:29:23] <OndraSter__> (but I can't imagine gear shifting with my left hand)
[16:29:24] <RikusW> Well you both are using the wrong side of the road :-P
[16:29:25] <N1njaneer> Just below Canada
[16:30:14] <RikusW> Gear shifting with my right hand would be weird...
[16:30:16] <OndraSter__> hahaha
[16:30:19] <OndraSter__> :P
[16:30:29] <OndraSter__> I tried gear shifting with my left (not in my car ofc)
[16:30:30] <OndraSter__> it was weird
[16:30:31] <RikusW> even though I'm left handed, I'm using a mouse with my right hand
[16:30:35] <Roklobsta> left hand shift is easy
[16:30:40] <Roklobsta> it's the pedal swapping that's the pain
[16:30:46] <OndraSter__> what pedal swapping?
[16:30:49] <RikusW> it actually feels weird to try using the mouse with my left hand
[16:30:50] <OndraSter__> gas is still on the right
[16:30:58] <Roklobsta> OndraSter__: er no.
[16:31:01] <OndraSter__> wat
[16:31:03] <OndraSter__> they lied to me
[16:31:10] <RikusW> fortunately the gas is still on the right...
[16:31:14] <OndraSter__> GUYS
[16:31:16] <Roklobsta> accel with left, brake with right
[16:31:16] <OndraSter__> MAKE UP YOUR MINDS
[16:31:35] <Roklobsta> accel is always closest pedal to stick
[16:31:45] <OndraSter__> Roklobsta vs RikusW
[16:31:46] <OndraSter__> FIGHT
[16:32:01] <RikusW> Roklobsta: In ZA gas is on the right, so is the driver
[16:32:21] <OndraSter__> http://answers.yahoo.com/question/index?qid=20080323235509AAHb95i
[16:32:36] <OndraSter__> not sure if Roklobsta was being real or just trolling :P
[16:32:37] <Roklobsta> in au accel is on left, driver on right, stick in the middle
[16:32:50] <OndraSter__> wow
[16:32:59] <OndraSter__> I exactly know what I would do the first time I would try driving in the AU then :D
[16:33:05] <RikusW> weird...
[16:33:09] <Roklobsta> i troll
[16:33:12] <OndraSter__> LOl
[16:33:15] <Roklobsta> au = ZA
[16:33:34] <OndraSter__> AU != ZA, AU ~= ZA
[16:33:38] <Roklobsta> = JP = TH = MY = SG = UK = NZ = PNG etc
[16:34:00] <Roklobsta> AU >> ZA
[16:34:09] <OndraSter__> I ment it as equivalence, they do not equal :P
[16:34:31] <OndraSter__> one has penguins, the other one does not
[16:34:40] <Roklobsta> surely za has penguins
[16:34:51] <RikusW> afaik there are some
[16:35:03] <OndraSter__> Roklobsta, AU has penguins? :o
[16:35:09] <OndraSter__> I ment it as ZA has, AU has not
[16:35:14] <Roklobsta> yes au has penguins
[16:35:17] <OndraSter__> :o
[16:35:21] <OndraSter__> trolling again? :D
[16:35:25] <Roklobsta> i saw a dead one on the beach the other day
[16:35:45] <OndraSter__> well I saw penguins at the ZOO here as well
[16:35:50] <Roklobsta> linus got bitten by a fairy penguin in a zoo here andnow we have a pengion as linux mascon
[16:35:53] <OndraSter__> I ment real, living, not in custody
[16:35:58] <OndraSter__> lol
[16:36:04] <OndraSter__> trolling night for Roklobsta it seems
[16:36:09] <N1njaneer> Magellanic penguins are warm-weather penguins :)
[16:36:24] <Roklobsta> http://en.wikipedia.org/wiki/Little_Penguin
[16:36:35] <Roklobsta> i have seen fairy penguins up as far as sydney
[16:36:57] <Roklobsta> in fact i was out fishing and a penguin swam past the boat and a shark fin was a few m behind. ;(
[16:40:33] <Roklobsta> wow i haven't configured the wdt *ever* on my project and now for some reason i am geting sdt resets
[16:40:34] <Roklobsta> wdt
[16:40:40] <Roklobsta> wtf
[16:40:50] <N1njaneer> ouch
[16:41:18] <OndraSter__> aren't you enabling it manually?
[16:41:19] <OndraSter__> in the code?
[16:43:52] <Roklobsta> just looking, the WDT fuse is 1 (unprogrammed)
[16:43:55] <Roklobsta> somethig has happened
[16:44:01] <Roklobsta> i think this jtag is wonky
[16:47:02] <Roklobsta> ok WDT FUSE is '1' (unprogrammed) but MCUSR says 0x18 JTAG and WDT reset
[16:47:11] <Roklobsta> FML
[17:06:58] <N1njaneer> Doing under AVRStudio?
[17:09:58] <Roklobsta> yes
[17:10:12] <Roklobsta> brekkie time, need some blood sugar and coffee before more debooing
[17:10:16] <Roklobsta> debooging
[17:11:01] <N1njaneer> Are you running the programmer directly for loading the flash file and setting fuses, are doing a debug run under Studio where it auto-uploads? I've seen some wonkyness at times with it setting unexpected fuses in the latter case.
[17:11:06] <Roklobsta> the 7.24 firmware for the dragion is buggy too
[17:11:14] <N1njaneer> +or are
[17:11:35] <Roklobsta> well, i am just going over the fuses and i hve a .fuse section in my code
[17:12:00] <N1njaneer> Hmm, have never done it like that. I always set the fuses discreetly and only send .hex files.
[17:12:35] <Roklobsta> hmmm
[17:12:48] <N1njaneer> When we run production there's a looping batch script that specifically sets everything on each device/unit. .elf has been a bit weird for me.
[17:15:45] <Roklobsta> as in not worked?
[17:20:48] <N1njaneer> It was hard to make sure it was behaving. Personally I like having a seperate file for the program, the fuses, and the lockbits. That way I can be sure of specifically what is going in. But that's just me. We often program many hundreds of AVR's per week.
[17:21:21] <N1njaneer> And just dumping in via ISP pads that pogo pins push against :)
[18:42:04] <Roklobsta> christ
[18:42:15] <Tom_itx> mmm?
[18:42:27] <Roklobsta> now what, neither isp or jtag can read the device id of my avr
[18:42:32] <N1njaneer> Hit it with a bigger hammer. A metric one.
[18:42:34] <Roklobsta> <head bang>
[18:42:48] <Roklobsta> what has happened
[18:42:52] <N1njaneer> Did you try power cycling the board completely?
[18:42:53] <Tom_itx> you really screwed the pooch this time
[18:42:55] <Roklobsta> yes
[18:43:30] <N1njaneer> Could have possible set the fuses to expect an external oscillator or such.
[18:43:48] <Roklobsta> fsck you elf fuses
[18:43:56] <N1njaneer> And a reminder that ISP/JTAG speed needs to be 1/8th or less of the external clock
[18:44:16] <Roklobsta> well the program is working
[18:44:21] <N1njaneer> Have done that where I speed up the ISP to 1Mhz, then turn on the clock div by 8 fuse, and suddently it stops responding.
[18:44:21] <Roklobsta> leds flash, uart works
[18:44:38] <Roklobsta> just can't isp/jtag it now
[18:44:41] <N1njaneer> Hmm, odd. Not that, then.
[18:44:44] <Roklobsta> ~11MHz clock
[18:44:53] <N1njaneer> Anything overlapping the ISP/JTAG pins?
[18:45:10] <Roklobsta> next step computer rebbot, maybe it's some stupid avrusbjtag crap
[18:45:26] <Roklobsta> even with isp i should be able to grab it's attention
[18:45:41] <N1njaneer> I have had that happen, too, where the ISP/JTAG device just gets funkified and needs the programmer, USB, or OS reset. :)
[18:45:55] <Roklobsta> i feel today i have taken 10000 steps backwards
[18:46:08] <N1njaneer> Are you getting a green light on your ISP, assuming you are using an Atmel one?
[18:46:37] <Roklobsta> well, restarting avrs6.1, powercycling device, swapping between dragon and mkii-cn does not work
[18:46:48] <Roklobsta> yes
[18:47:37] <Roklobsta> rebootus brb
[18:47:39] <N1njaneer> Other thing I've had happen is that the ribbon cables get old over time and strands start to break internally such that you get intermittant connections to the ISP
[18:47:47] <Roklobsta> it's not that old
[18:48:01] <N1njaneer> The older JTAGICE2 was even worse
[19:01:28] <Roklobsta> "Please verify device selection, interface settings, target power and connections to the target device."
[19:01:32] * Roklobsta headbangs
[19:01:53] <Roklobsta> that's on ISP
[19:03:07] <N1njaneer> Any overlapped connections on the ISP pins?
[19:03:29] <N1njaneer> Peripherals, etc?
[19:04:35] <Roklobsta> wow not even avr ISP mk-II
[19:04:49] <Roklobsta> so all 3 devices i have don't walk to it on ISp or JTAG
[19:04:52] <Roklobsta> what
[19:04:53] <Roklobsta> have
[19:04:54] <Roklobsta> i
[19:04:55] <Roklobsta> done
[19:04:58] <N1njaneer> Any overlapped connections on the ISP pins?
[19:05:08] <Roklobsta> can't be
[19:05:11] <Roklobsta> shoulnd't be
[19:05:24] <Roklobsta> did i fsck a fuse?
[19:05:39] <N1njaneer> Possibly, if you somehow turned off both ISP and JTAG
[19:05:49] <Roklobsta> i should always be able to isp it no matter what the fuses right
[19:06:32] <N1njaneer> Well you CAN disable the ISP interface on it. JTAG you certainly can.
[19:06:46] <N1njaneer> What AVR?
[19:08:38] <Roklobsta> 1280 bbl
[19:09:24] <Casper> if you set the ext clock fuse then all programmation attempt will fail if you don t connect a clock fuse
[19:09:40] <Roklobsta> uh oh
[19:09:48] <Roklobsta> bbl
[19:09:54] <N1njaneer> Already checked that - it's running his code, so clocking is working
[19:10:45] <N1njaneer> Wish it was that, as you can generally recover it by injecting 1 Mhz on the clock pins with a function generator or oscillator and revive
[19:11:31] <Casper> low pin count device? those have a resett disable fuse
[19:12:03] <N1njaneer> That could possibly be it, too.
[19:12:11] <N1njaneer> He said it's an ATMEGA1280
[19:12:42] <N1njaneer> Datasheet does indicate those will allow for HV parallel programming. May be the only way to recover it save for switching out the chip.
[19:13:51] <N1njaneer> 1280 doesn't have a reset-disable fuse, looking at it now.
[19:14:16] <N1njaneer> My suspicion is that the SPIEN and JTAGEN may have both gotten cleared.
[19:15:04] <N1njaneer> (another reason I prefer setting fuses directly rather than via the ELF - AVR Device Programming actually warns you with a dialog if you're about to disable either the ISP or JTAG interfaces)
[19:58:18] <MarkX> is there a C equivelent of pgm_read_word() which doesn't require the addition of an avr specific library?
[20:04:04] <N1njaneer> Not directly, no. Unless you want to interject the inline assembler.
[20:05:02] <N1njaneer> Normal addressing pulls straight from RAM, and the Harvard architecture necessitates a different call to get at the program data.
[20:05:28] <N1njaneer> Any reason you don't just want to add #include "avr/pgmspace.h" to your files?
[20:07:12] <Valen> anybody know any simple examples of parsing a serial stream?
[20:07:25] <N1njaneer> Can you be more specific?
[20:07:48] <Valen> I'll be using lufa in the usb>serial demo mode
[20:08:01] <Valen> I need to read in a few 16 bit variables and send back the same
[20:08:19] <Valen> so I didn't want any super clomplex 15 function call deep magic
[20:08:33] <N1njaneer> sscanf() if it's ascii and not binary :)
[20:09:01] <Valen> hmm thats not a terrible idea
[20:09:05] <Valen> I was going to send binary
[20:09:13] <Valen> but ascii could be much nicer
[20:09:25] <N1njaneer> If it's binary, just ensure frame alignment and cast directly and copy. Just be sure of endianness :)
[20:09:49] <Valen> I'm worried about things like loosing a byte and everything getting out of order
[20:10:02] <N1njaneer> Add framing and/or checksum
[20:10:11] <Valen> see it starts to get complex
[20:10:24] <Valen> I have done it before, just not in C
[20:10:29] <Valen> and I'm pretty weak with C
[20:10:49] <N1njaneer> Work through the method in pseudocode, then work through the syntax.
[20:11:06] <Valen> I'd much rather copy somebody elses work ;->
[20:11:58] <Valen> also I don't know enough C to know how to do the translation well
[20:12:10] <Valen> I don't know what functions are around that are usefull for this application
[20:12:30] <N1njaneer> sscanf() will do the ascii conversions of data
[20:12:43] <Valen> that built into AVR?
[20:12:49] <Valen> avrgcc
[20:13:25] <N1njaneer> So you can say something like sscanf(buffer, "%d %d %d", &val1, &val2, &val3); and it will parse something like "100 45 8000" and place them in val1 thru val3
[20:13:52] <Valen> wow that is nice
[20:14:11] <Valen> that just a /n terminated string as the input or something?
[20:14:32] <N1njaneer> Yes, sscanf() is a standard C library in #include <stdio.h>
[20:14:43] <N1njaneer> Actually a null terminated string is all it needs.
[20:15:31] <N1njaneer> C uses 0x00 as the marker for the end of string data. sscanf() will typically ignore the other characters unless it's specifically looking for them in the framing, etc.
[20:15:40] <N1njaneer> http://www.cplusplus.com/reference/cstdio/sscanf/
[20:16:21] <Valen> see I get confused with the C++ examples lol
[20:17:00] <N1njaneer> Just keep in mind that if you put a LOT of string literals in your sscanf()'s they'll eat up RAM rather quickly unless you are specifically placing them in flash program memory, which is where you get in to needing sscanf_P() and friends
[20:17:32] <N1njaneer> But use the basic one until you get it working and/or run out of RAM, if ever. If it's just one or two sscanf() probably not a problem at all
[20:18:13] <N1njaneer> The link above example is just straight C
[20:18:16] <Valen> by string literals you mean the %d?
[20:18:30] <N1njaneer> But if you've not worked with the syntax before, it can be a bit weird to get a handle on.
[20:18:40] <N1njaneer> No, the "%d %d" part
[20:19:07] <Valen> ahh
[20:19:21] <Valen> well I only need the one of those ;->
[20:19:31] <Valen> I just need to load up 2 16 bit timers
[20:19:57] <N1njaneer> When you have a string enclosed inside of double-quotes in the program, it is referred to as a string literal, as it is stored in memory and the compiler will automatically point the function where it appears in memory :)
[20:20:06] <N1njaneer> Easy enough then!
[20:20:25] <N1njaneer> Probably want to use unsigned ints so you can set your timers above 32767
[20:20:38] <Valen> uint16_t ftw ;->
[20:20:48] <MarkX> N1njaneer: sorry for the late response, i'm actually trying some code on an online C compiler (www.codepad.org)
[20:20:50] <N1njaneer> that works
[20:20:59] <Valen> Any suggestions on where to find more about how to get from taking individual bytes in and getting it into a format suitable for sscanf?
[20:21:00] <MarkX> so i can't include avr/*
[20:21:11] <N1njaneer> MarkX: Cool, not familar with it
[20:21:25] <N1njaneer> Well, if you aren't doing it on an AVR, you can just drop all of that stuff anyhow
[20:21:44] <N1njaneer> Just use the non _P version of functions and eliminate the pgm_read_whatevers
[20:22:36] <MarkX> i'm sorry i don't understand.
http://pastebin.com/DGmS8F8M << that is the code in question, i would like to change line 18 (for example) to work in this online enviornment (totally unrelated to AVR)
[20:22:41] <N1njaneer> Those are kind of a necessary evil tacked on with the AVR's due to the Harvard architecture (and where applicable the 64K limit of direct addressing on larger devices, where you usually have to add _far to it)
[20:25:30] <MarkX> i thought it would be something simple like "desc_val = read_word(list) "
[20:25:35] <MarkX> but apparently not
[20:25:45] <N1njaneer> You should be able to get that to work by dropping "PROGMEM" from the top line, and changing "desc_val = pgm_read_word(list)" to something like "desc_value = *((uint16_t *)list);"
[20:26:39] <N1njaneer> In this case pgm_read_word() is necessary on the AVR to retrieve the values from the flash-stored descriptor list structure. The function essential works like a pointer value dereference
[20:27:14] <MarkX> ah ok, let me try that
[20:27:49] <N1njaneer> read_word returns a 16 bit value back, so in the case of bypassing that, you need to take the "list" pinter (which I assume is a void * or such) and cast the pointer in to a unit16 type so it knows you want to grab 16 bits work :)
[20:29:53] <MarkX> not going to lie, that was total gibberish but that's all cause of my lack of C knowledge
[20:30:02] <MarkX> let me read up some more on csts
[20:30:03] <MarkX> casts*
[20:31:08] <N1njaneer> In your example, list is a pointer that is pointing to the first descriptor - a 16 bit value
[20:31:35] <MarkX> right
[20:31:38] <N1njaneer> I can't see your full code, but I assume that list is established as something like "uint16_t *list"
[20:32:29] <MarkX> const uint8_t *list;
[20:33:00] <N1njaneer> Remember that pointer is just an arrow (and always an arrow!) that points to some address in memory. The *type* of a pointer tells the compiler the kind of data it should sanically be pointing at, and the type of data also lets it know the size that it should increment the pointer by.
[20:33:11] <N1njaneer> Okay, that works as well.
[20:33:23] <N1njaneer> So list is a pointer of type unsigned 8 bits.
[20:33:52] <N1njaneer> When you do "list = (const uint8_t *)descriptor_list;" it is pointing list at the start of the descriptor struct
[20:34:04] <MarkX> go on
[20:34:39] <N1njaneer> The cast is necessary because descriptor_list is NOT of type uint8_t, so the compiler will complain and warn you / error out
[20:35:09] <N1njaneer> The cast force-converts it, and effectively switches the type from descriptor_list_struct to uint8
[20:35:56] <N1njaneer> So when you go down further, desc_val (which I assume is a uint16_t?) is going to be assigned to the 16 bits of value that the list pointer is currently pointing at.
[20:36:24] <N1njaneer> Again, in this case, list is just a pointer in to memory, and in this usage a pretty generic one at that, since it is just pointing to some bytes.
[20:37:15] <MarkX> yes its uint16_t
[20:37:45] <N1njaneer> desc_val = *((uint16_t *)list); will first cast list in to a uint16 type (because you want to grab 16 bits worth of data, not 8) and then the leading * dereferences the pointer to the actual value. And presto, in the first time through the loop, assigns desc_val to 0x100;
[20:38:13] <MarkX> beauty
[20:38:21] <MarkX> but what is the point of the * after the =
[20:38:26] <N1njaneer> Further down, list += 2; increments the list pointer by two bytes, since list is a uint8_t pointer.
[20:38:42] <N1njaneer> If it was, say, a uint16_t pointer, this would be list += 1; etc
[20:39:07] <N1njaneer> This code is admittedly a bit hard to follow since there's some lower-level twiddling going on.
[20:39:36] <MarkX> yea its not fun, ive spent the last few weeks rewriting it with full comments on every line to help anyone else that might need it :P
[20:39:45] <N1njaneer> It could honestly be rewritten for clarify in a few ways, but embedded programmers often brush away clarity in the interest of just getting stuff written :)
[20:40:07] <N1njaneer> Hopefully that helps, though
[20:40:44] <MarkX> http://pastebin.com/0NSnCb2e << very poorly formatted example of what i've been doing :P
[20:41:38] <N1njaneer> It's useful to do that to make things easier to follow
[20:42:14] <MarkX> yep
[20:42:38] <MarkX> for this "desc_val = *((uint16_t *)list);" what is the point of the * after the = ?
[20:43:06] <N1njaneer> That does the dereference. It says "use the value of what the pointer is pointing to" rather than the pointer itself.
[20:43:14] <MarkX> (uint16_t *)list forces a change in cast to uint16_t for those 2 bytes of code
[20:43:15] <MarkX> ahhhh
[20:43:16] <MarkX> ok cool
[20:43:36] <N1njaneer> 2 bytes of data, yeah.
[20:43:45] <MarkX> err yea data*
[20:43:50] <MarkX> you're a great explainer btw
[20:44:03] <MarkX> thank you for helping
[20:44:13] <N1njaneer> For instance, if you did a *(uint8_t)list in that, it would only pull the first data byte of the 0x100.
[20:44:47] <N1njaneer> You're welcome!
[20:45:16] <N1njaneer> Give a man a fish and he will make sushi, teach a man to fish and he'll open a Habachi chain.
[20:46:13] <MarkX> wisdom :D
[20:47:21] <N1njaneer> I'm also a fan of adding () wherever necessary to make things clearer. It also disambiguates the order of operations, which can really drive you up the wall when you THINK it's doing one thing, but the compiler is doing it in a different order, and both methods are valid syntax :)
[20:48:36] <Valen> () ALL THE THINGS!
[20:49:01] <N1njaneer> Twenty sets of () to rule them all.
[20:50:28] <N1njaneer> When you are doing byte-level stuff like your descriptor list, it is often useful to make the main pointer you are working with a "void *" to remind yourself that you are working with memory addresses directly without inherent type.
[20:51:04] <N1njaneer> Having the void * there will force you to HAVE to cast the pointer type before dereferencing. If you forget to put the cast in there, the compiler will error out.
[20:53:12] <Casper> N1njaneer: same here
[20:53:21] <Casper> it make stuff SO easier to read too
[20:53:34] <Casper> and the mistakes easier to find
[20:53:39] <N1njaneer> Absolutely.
[20:53:56] <MarkX> N1njaneer: makes sense
[20:53:57] <N1njaneer> I'd rather the compiler throw an error or warning, than to compile code that I've written incorrectly.
[20:54:15] <MarkX> but for now it was all for testing purposes as me and a friend we arguing what the code actually does
[20:54:24] <MarkX> http://codepad.org/g35UMuJp << result
[20:54:28] <MarkX> i was right :P
[20:54:43] <Casper> foo = x * y + 4; or... foo = (x * y) + 4; or foo = x * (y + 4); .....
[20:55:17] <N1njaneer> Multiplication before addition, like in algebra :)
[20:55:24] <Casper> yup
[20:55:40] <Casper> but the first example, it's not clear what the programmer wanted
[20:56:16] <Casper> second is clear, and same as first, but maybe the tired programmer wanted the third? :D
[20:56:28] <MarkX> heh
[20:56:49] <N1njaneer> Mark: Got it working correctly then?
[20:58:40] <MarkX> well it was all a test. as you see in the code, if wIndex or wValue don't match, it moves on to the next struct. I thought it would move from 0x0100 to 0x0200 where as my more knowledgeable friend thought it would disregard descriptor_list[] entirely and move on to the next struct (if available)
[20:59:00] <MarkX> confusing i know, the argument we had was even more confusing
[20:59:17] <MarkX> but yes, as far as tests go, it worked and i can comment it accordingly now :)
[20:59:34] <N1njaneer> Awesome
[21:02:27] <N1njaneer> Alright, time to go hit the gym. "Gotta get back to 'da choppah!"
[21:02:38] <MarkX> take care
[21:02:45] <N1njaneer> Good luck to you guys on your respective projects!
[21:17:52] <Roklobsta> N1njaneer: here's my fuse code.
http://pastebin.com/fSuP5AS6 Please tell me I can recover without HV....
[21:18:06] <Roklobsta> or anyone...
[21:20:48] <MarkX> i'm not ballsy enough yet to touch fuses...
[22:01:57] <Roklobsta> oh crap, I am a complete nonce. I |ed them, not &then
[22:02:00] <Roklobsta> them
[22:04:53] <Tom_itx> you're setting them in code?
[22:06:37] <Roklobsta> yyyyesss
[22:06:46] <Roklobsta> i thin ki have disabled isp and jtag
[22:29:42] <Roklobsta> you know, HV programming the 1280 on a 3.4V system should be a blast.
[22:49:00] <N1njaneer> Rok: When you dumped in the code, did you do it via ISP or JTAG?
[22:50:39] <N1njaneer> According to the datasheet, if you are loading via serial, you should not be able to clear the SPIEN fuse.
[22:52:07] <Roklobsta> erm jtag
[22:52:09] <N1njaneer> Also, what speed is your ISP set to? If you are setting CLKDIV8 and you have an 11Mhz clock, you need to make sure the ISP is set pretty low.
[22:52:31] <Roklobsta> well the ledsand uart are running as usual, which is weird
[22:52:33] <N1njaneer> I would set it as low as the programmer will go and see if you have any luck.
[22:52:38] <Roklobsta> ok
[22:52:54] <Roklobsta> stupid me, i ORed the damned fuse definitions, not AND
[22:53:18] <N1njaneer> On mine here, that's 2.152Khz. Slow as balls, but you should be able to get a signature read and set fuses.
[22:53:31] <N1njaneer> No, you'd want to OR them. AND'ing wouldn't let you combine
[22:53:43] <N1njaneer> OR for combine, AND for mask, XOR for flip :)
[22:54:36] <Roklobsta> http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html needs and
[22:54:58] <Roklobsta> as they are defined as ~_BV(bitnum)
[22:54:58] <N1njaneer> That's a bizzare way of doing it.
[22:55:29] <N1njaneer> Ahh, makes sense. As I said, I've never set fuses in this manner.
[22:55:42] <Roklobsta> if there are any other suggestions apart from repalcing the chip or HV PP programming I am open to ideas
[22:56:20] <N1njaneer> Well, seeing how the fuse options are layed out with that, yeah, I'd say you probably turned off SPI and JTAG
[22:56:39] <N1njaneer> And if you programmed via JTAG that would allow you to disable SPI.
[22:56:52] <N1njaneer> So I think HV PP or chip replace is the only way to go.
[22:57:07] <Roklobsta> *%#^&%@!(%^!@!!!!!!!!
[22:57:13] <N1njaneer> Too bad you're not here - would take me all of a couple minutes to swap the chip for you. :)
[22:57:31] <Roklobsta> i have a spare sitting on a defunct board.
[22:57:45] <N1njaneer> Do you have the means to swap them?
[22:57:57] <Roklobsta> yeah i can do it. FSCK
[22:58:11] <Roklobsta> i have blowtorch and pliers
[22:58:13] <N1njaneer> Well, at least you have options.
[22:58:21] <N1njaneer> Got a heat-gun?
[22:58:30] <Roklobsta> no
[22:58:39] <N1njaneer> Are you in the US?
[22:58:42] <Roklobsta> noooooooooooo
[22:58:45] <N1njaneer> Awww
[22:59:02] <Roklobsta> NSA, if you're listening, pony up some ideas.
[22:59:40] <Roklobsta> i'll just use my messy iron, flux, and copper wick method
[22:59:41] <N1njaneer> Too bad. We have a cheap chain here called Harbor Freight - their $12 heat-guns are nice.
[23:00:01] <Roklobsta> oh i am so mad with myself
[23:00:09] <N1njaneer> They last about 2-3 years for us, usually before bursting in to flames or somehow catestophically failing. Then you go buy another one.
[23:00:39] <N1njaneer> The work really really for pulling off QFP's if you are careful. $12 heat-gun works as well as the $20K Pace rework station
[23:01:12] <N1njaneer> Well, look on the bright side. a> you have a spare chip b> you'll never forget to use & instead of | ever again on fuses. :)
[23:01:25] <N1njaneer> Trial by fire. Or perhaps blowtorch
[23:01:41] <Roklobsta> url me the heat gun, i might go get one. I am good at getting qfp's OFF but that's coz I have a mint qfp to replace it.
[23:01:56] <Roklobsta> i might go get a gun today
[23:02:02] <Roklobsta> show me the heat gun
[23:02:20] <N1njaneer> Sorry, $15 - price went up!
http://www.harborfreight.com/1500-watt-dual-temperature-heat-gun-572-1112-96289.html
[23:02:30] <Roklobsta> i can set up HV programming to the dragon or replace the chip.
[23:02:50] <N1njaneer> Just use the low setting and heat slowly in circles over about a minute, then lift the chip off with tweezers.
[23:03:01] <Roklobsta> how do you avoid cooking everything else
[23:03:08] <Roklobsta> tin foil mask?
[23:03:23] <Roklobsta> i might go get gun. i can claim it on tax
[23:03:27] <N1njaneer> It's okay if nearby solder reflows a bit - just don't bang anything else in the vicinity
[23:03:37] <Roklobsta> ok gun tim
[23:04:18] <N1njaneer> When we run double-sided boards in the oven, you reflow everything twice. The stuff that has already flowed on the first cycle will pretty well stay put. The flux has already activated and mostly burned off, so it just doesn't actually "flow" like new product, but it doesn't hurt anything.
[23:04:38] <N1njaneer> Er everything == one of the sides twice
[23:09:03] <Roklobsta> Heatgun or this:
http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon.htm#AVRDragon_HVSP_Description.htm
[23:09:07] <Roklobsta> heatgun wins
[23:10:26] <N1njaneer> LOL yeah, I can't say that I've EVER stooped to HV programming in the past 12 years of AVR stuff
[23:10:37] <N1njaneer> Too much time vs just put on another chip
[23:10:46] <Roklobsta> with something like a 1280 you'd never ever ever use it
[23:11:04] <Roklobsta> anyway, there's other stuff on the pins that'd intefere with the signal
[23:11:09] <N1njaneer> Though I think the only thing I ever did was get clock set to external oscillator, and had to inject 1Mhz to recover it. And that was only one time :)
[23:11:43] <Roklobsta> another day wasted
[23:12:18] <N1njaneer> Oh well, consider it learning.
[23:13:34] <Roklobsta> yeah, don't try to update you fuse code and organise breakkie for the kids concurrently.
[23:18:40] <N1njaneer> Rok: Where 'ya at geographically?
[23:19:02] <Roklobsta> .au
[23:19:14] <Roklobsta> the side that faces antartica
[23:19:15] <N1njaneer> Ahh Perth, AU according to your whois. Nice!
[23:19:26] <Roklobsta> perth is 3000km away
[23:19:35] <N1njaneer> LOL oh wait, that's where the server is :)
