Back
[01:33:25] <inflex> okay, this is odd
[01:33:37] <inflex> if I monitor one channel on the ADC it's fine.... or the other, it's fine
[01:33:43] <inflex> but if I try switching between them... it's a disaster
[01:33:48] <inflex> and yes, I discard the first results
[01:34:04] <inflex> (especially too that I'm switching between Vrefs
[01:36:33] <inflex> eg, on Ch1, I should get ~510.... on Ch6 I should get 63.... but instead it's a hellish mishmash of bullcrap
[01:41:59] <soul-d> mmm
[01:50:46] <inflex> yeah, it's odd, I know
[01:52:32] <soul-d> i did try reading out a touchscreen that had 1channel that read correctly but other din't i think i was smart enough to try all inputs diferently but i dropped it cause avr was doing lots of other things to still have to do it again someday
[01:53:17] <soul-d> but might be difrernt problem since it was a particular direction that din't make sense
[01:54:34] * inflex is confounded because it just doesn't seem to make any logical sense
[01:55:28] <inflex> I'm not even pulling any magical tricks for speed, I'm just doing slow process of set a new MUX, start the conversion, discard, start another conversion, send result.... then set a new MUX....
[01:56:22] <Casper> weird, when I was doing 8 channel reading I was setting admux, start conversion, process, start over
[01:56:31] <Casper> and all channel was reading correctly
[01:56:54] <inflex> Casper: yeah, go figure... not sure what I'm doing wrong here - dropping all optimisations and ancillary stuff... time to go back to basics
[02:00:00] <inflex> yep, each channel works fine on its own
[02:01:41] <inflex> mmm.. works fine if I don't change the REF selections
[02:04:03] <inflex> sheeesh, even tried disabling the ADC between
[02:05:20] <Casper> hmmm
[02:05:31] <Casper> isn't there something about a delay between aref change?
[02:05:41] <inflex> there is, but surely not -that- long... I wait 100ms !!!
[02:05:48] <inflex> and do 2 dummy conversions
[02:06:02] <Casper> and also... have you done the math on the stabilising cap on aref?
[02:06:26] <inflex> no, but it's a 100nF ceramic on there atm
[02:06:32] <Casper> I know it's an high impedance output, so might take lots of time to charge your capacitor to the right voltage
[02:11:37] <inflex> there certainly is a time delay there...
[02:11:52] <inflex> here's a sequence, I do 50 samples of each, then switch
[02:11:54] <inflex> 529 529 0 0 2 2 4 4 4 7 7 7 9 9 9 16 16 16 14 14 1
[02:12:35] <inflex> oopos, supposed to be 14 for the last one :)
[02:12:40] <inflex> (which is where it stabilizes to
[02:13:46] <inflex> wonder if I just go with AREF
[02:17:06] <inflex> What sort of values do you guys use for the Aref cap?
[02:17:11] <inflex> maybe if I change it to 1nF
[02:23:34] <inflex> yeah, changing to 1nF fixes that
[02:23:44] <inflex> I get a bit of an overshoot on the first value but that's to be anticipated
[02:31:59] <inflex> I suppose it's a good reason not to be changing Vrefs
[03:21:49] <soul-d> http://i.imgur.com/0Ciot.jpg i think i deserved some cofffee :) looks i got myself a working logic analyzer ( without writing software ;) )
[03:30:55] <inflex> one you wrote yourself or
[03:30:56] <inflex> ?
[03:33:52] <soul-d> using altera dev board and it's signaltapII just wire some outputs to converter board and export logs to "vcd " file for gtk wave
[03:35:40] <soul-d> although disadvantage is that some changed might need you to re synthesize
[03:35:47] <soul-d> in triggers
[03:36:56] <soul-d> but found there are some existing type's of fpga analyzers +software sump i thought is called thought haven't looked at it yet
[03:41:05] <ziph> soul-d: You can't build demuxers to do the triggering set up dynamically?
[03:43:49] <soul-d> well i meant there are certain options that causes it but indeed most is dynamic and you could still turn on increcemental compilation stuff so only changes are done
[03:44:13] <ziph> Is it entirely synchronous?
[03:44:28] <soul-d> how you mean ?
[03:44:53] <ziph> Is the FPGA design entirely synchronous? (e.g. every FF runs from the same global clock)
[03:45:40] <soul-d> oh i used a pll 4 times the clock of target avr is running for signal tap clock source
[03:46:39] <soul-d> i geuss this signaltap is synchronious i read last night there was an option to do async with a triggout function
[03:46:49] <soul-d> so you can cross clock domains
[03:48:51] <soul-d> but thats what i mean since i mostly don't have a clue testing it out for stuff that requires re-synthesizing cost lot of time
[03:50:55] <ziph> What required a resynth?
[03:52:04] <soul-d> if you change storage qualifieres for example possibly some other advanced futures
[03:53:12] <soul-d> http://i.imgur.com/wCE58.jpg my messy table
[03:53:59] <soul-d> but true now it's set for this setup i don't need to touch it to much except log
[03:54:16] <soul-d> only need more wires so i have 16bit
[05:44:10] <abcminiuser> MY EYES
[05:44:17] <abcminiuser> Reddit WTF has ruined me
[05:44:31] <tlvb> ?
[05:45:36] <CapnKernel> I think I missed something.
[05:45:47] <CapnKernel> Is this a "goatse" kind of "MY EYES"?
[05:46:02] <CapnKernel> "2g1c" kind of "MY EYES"?
[05:46:20] <CapnKernel> "tubgirl" kind of "MY EYES"
[05:46:35] <inflex> lemonparty ?
[05:46:42] <tlvb> I don't think reddit wtf allows that kind of nsfw content, but I'm not sure
[05:46:43] <inflex> Sulphuric acid?
[05:46:57] <tlvb> ze goggles?
[05:47:07] * inflex claps as tlvb gets the reference
[05:48:40] <abcminiuser> CapnKernel, that and more
[05:48:50] <abcminiuser> tlvb, haven't checked back today?
[05:48:57] <abcminiuser> They've put it "back to it's roots"
[05:49:09] <abcminiuser> Which means now my front page is full of YYAARRRRRGGGGG
[05:49:17] <tlvb> I've heard something about it yes, but I have not checked it out specifically
[05:49:20] * CapnKernel is still floundering
[05:49:27] <CapnKernel> Or is it foundering
[05:49:29] <abcminiuser> Don't :P
[05:49:37] <CapnKernel> I don't know, I'm a little drunk and 7,000 km from home.
[05:49:38] <abcminiuser> CapnKernel, www.reddit.com/r/wtf
[05:57:19] <karlp> hooray for unnecessary bugs.
[05:57:32] <karlp> I'd fixed the same bug on a different device, never applied the fix to this device.
[05:57:51] <karlp> remember, pullups (internal are ok) are important for rx lines on rs485 transceivers.
[06:12:44] <jacekowski> nope
[06:12:48] <jacekowski> no pullups in rs485
[06:13:01] <jacekowski> those are biasing resistors
[06:13:14] <jacekowski> and terminating resistors
[06:13:17] <jacekowski> different thing
[06:13:50] <RikusW> hi scuzzy
[06:14:19] <RikusW> starting to add support for LUFACDC bootloader
[06:14:29] <karlp> jacekowski: no, I mean on teh rx output side of the transceiver
[06:14:45] <karlp> not on the 485 line itself,
[06:14:54] <karlp> I'll bow to your proven experie3nce on that side :)
[06:22:58] <KebabBob> I have a few avr85 chips, and I was wondering if there's a simple(ish) way to measure ac current with them?
[06:23:33] <RikusW> tiny85 ?
[06:24:00] <KebabBob> yeah
[06:24:09] <karlp> measure ac current is a pretty broad area...
[06:24:18] <KebabBob> 50hz ac current
[06:24:36] <KebabBob> As broadly as possible, but I have no idea what limitations there are
[06:25:07] <KebabBob> I'm trying to reduce power usage in my home, so I want to measure outlets I suspect are using alot of power
[06:25:24] <KebabBob> standby power and also stuff like my refrigerator and such
[06:26:29] <karlp> none of them are going to be as simple as you'd like :)
[06:26:38] <karlp> chepeast and fastest is to buy a few of plug in meters.
[06:27:27] <KebabBob> where's the fun in that?
[06:27:29] <KebabBob> :)
[06:27:44] <KebabBob> Risk of shocking myself with mains is too enticing
[06:28:07] <RikusW> 110V or 220V ?
[06:28:17] <RikusW> or 380V 3 phase ;)
[06:28:29] <KebabBob> 230v, 50hz :)
[06:28:59] <RikusW> not too bad if you have good shoes
[06:29:04] <KebabBob> I do have 3x63A coming into my house, so that might be a fun side project too ;)
[06:29:16] <RikusW> 3 phase ?
[06:29:19] <KebabBob> Yeah
[06:29:46] <RikusW> what country is that ? white blue red ?
[06:29:48] <KebabBob> But the original plan was to measure something like 50-1000w
[06:29:51] <KebabBob> iceland
[06:30:27] <RikusW> there is current transformers so you're completely isolated
[06:30:39] <RikusW> maybe thats a good idea to use one...
[06:30:59] <KebabBob> I'm currently measuring power usage for the whole house by counting blinks on the utility company meter, but want to go a little more granular for some other things
[06:32:04] <RikusW> photodiode ?
[06:32:14] <KebabBob> ldr actually
[06:32:55] <karlp> KebabBob: looking for work?
[06:33:12] <karlp> www.remake.is is hiring if you _really_ want to play with mains and embedded :)
[06:33:30] <KebabBob> lol nah, brew.is will suffice kalli ;)
[06:33:50] <karlp> well I don't know who "KebabBob" is :)
[06:33:54] <karlp> now I do :)
[06:34:13] <KebabBob> Yeah I was pondering if I should play some prank after looking up your whois :)
[06:34:24] <karlp> but we are looking to see if we can sell some of our hardware parts for hobbyists
[06:36:17] <KebabBob> I'm an electrical newbie, but was looking at some blog where a guy used attiny85 and a 0.1ohm shunt to measure ac
[06:36:36] <KebabBob> Looked simple but wanted to ask around before trying to kill myself :D
[06:36:55] <RikusW> abcminiuser: why did you #define AVR_SIGNATURE_1 0x1E when io.h already do -> #define SIGNATURE_0 0x1E ??
[06:37:03] <RikusW> in the LUFACDC code
[06:37:03] <abcminiuser> RikusW, legacy
[06:37:12] <abcminiuser> Previous popular WinAVR distribution lacked it
[06:37:20] <RikusW> ugh
[06:37:21] <abcminiuser> Also, the old Linux packages lacked it too
[06:37:29] <abcminiuser> It sucks, I know
[06:37:33] <karlp> KebabBob: if you just want to measure current, and aren't concerned about the changing voltage too much, using a current transformer is the safest,
[06:37:36] <abcminiuser> But since I've already done it, might as well keep it
[06:37:41] <RikusW> yeah
[06:38:06] <RikusW> working in LUFACDC bootloader support right now
[06:38:09] <karlp> KebabBob: something like:
http://www.seeedstudio.com/depot/noninvasive-ac-current-sensor-100a-max-p-547.html?cPath=144_154
[06:38:35] <karlp> you'll get an AC voltage proportional to the current, and you can measure that with the ADC on the tiny85
[06:39:46] <inflex> thing is, you need voltage an current, because they're not quite in phase due to power-factors
[06:40:07] <karlp> depends how accurate you want, as I said.
[06:40:22] <karlp> you can get a pretty good idea of what's going on, without exact billable numbers, by just comparing over time.
[06:42:19] <abcminiuser> RikusW, latest trunk has an app API too
[06:43:01] <RikusW> seems avr109 is quite simple, it will fit in my framework
[06:43:14] <RikusW> but I'll download the latest too and have a look
[06:44:31] <KebabBob> $11.50 isn't too bad either
[06:44:38] <KebabBob> And I could throw in a batch of pcbs :P
[07:06:39] <scuzzy> hey Rickta59
[07:06:40] <scuzzy> errr
[07:06:43] <scuzzy> Hey RikusW
[07:06:45] <scuzzy> how you doing dude?
[07:07:29] <RikusW> fine you ?
[07:07:41] <RikusW> busy on the LUFACDC code now
[07:09:34] <RikusW> scuzzy: what are you up to ?
[07:10:45] <scuzzy> trying to get hold of people at work mostly
[07:10:54] <scuzzy> It's a disgrace
[07:11:09] <scuzzy> anyway
[07:11:10] <scuzzy> what you up to?
[07:11:18] <RikusW> LUFACDC code
[07:11:23] <RikusW> for RavrProg
[07:11:31] <scuzzy> oh
[07:11:33] <scuzzy> wowzer
[07:11:36] <scuzzy> I was going to implement that
[07:11:39] <RikusW> Seems to fit nicely into my framework too :)
[07:11:44] <scuzzy> avr109?
[07:11:51] <RikusW> Well you'll be the beta tester
[07:11:56] <scuzzy> damn right I will
[07:12:06] <RikusW> just enough of avr109 to make LUFACDC work
[07:20:36] <DanFrederiksen> how many clockcycles does a for loop take with no content in atmega? 2 cycles or more?
[07:21:03] <RikusW> check the disasm
[07:21:14] <RikusW> probably more than 2
[07:21:33] <tlvb> unless it is optimized away entirely
[07:21:34] <RikusW> 3 maybe
[07:21:44] <tlvb> it also depends on the exit condition
[07:22:42] <DanFrederiksen> or to ask another way, is there a way to spend a certain amount of clockcycles? no timer nonsense
[07:22:48] <DanFrederiksen> or wait
[07:22:55] <tlvb> volatile asm?
[07:23:25] <tlvb> if it is few clock cycles
[07:23:35] <DanFrederiksen> volatile?
[07:24:11] <DanFrederiksen> I want to sample the current near the end of the pwm pulse
[07:24:16] <tlvb> you can have fields of assembler code in your c program with volatile asm( ... )
[07:24:36] <tlvb> there is also
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html
[07:25:06] <tlvb> but if it cycle delays and not time delays, you might want delay_basic.h, although I've never used those
[07:27:31] <DanFrederiksen> sounds like the very for loop I was proposing. and it says 3 cycles per each. so I'll probaly just code it. thanks
[07:28:43] <DanFrederiksen> realtime stuff feels too volatile
[07:29:13] <DanFrederiksen> particularly when there is no debugger implemented
[07:29:33] <DanFrederiksen> avr5 has no atmega8 support right?
[07:29:38] <DanFrederiksen> studio
[07:30:10] <DanFrederiksen> for debugging
[07:30:33] <DanFrederiksen> I think avr studio 4 did but they had to go bloat and useless with 5
[07:30:44] <scuzzy> RikusW: fantastic. You're using the qt serial abstract library right?
[07:31:02] <RikusW> qextserial
[07:31:12] <RikusW> qt4.2 don't have serial support
[07:31:55] <RikusW> DanFrederiksen: mega8 don't have debug support builting
[07:32:06] <RikusW> you'll have to use m168 or 328
[07:32:09] <RikusW> or m324a
[07:32:22] <DanFrederiksen> RikusW, is that compatible enough?
[07:32:55] <inflex> at ;east the m88 series does have the debug support
[07:32:58] <RikusW> m168 is like m8
[07:33:09] <RikusW> with dW support
[07:33:10] <DanFrederiksen> or do you mean debug connected to the hardware?
[07:33:12] <inflex> yeah, they're all pin-compatible
[07:33:13] <RikusW> debugWire
[07:33:14] <DanFrederiksen> I just mean simulated
[07:33:29] <RikusW> should be the same about
[07:33:38] <RikusW> try mega88
[07:34:05] <scuzzy> RikusW: afaik, you've always had to download qextserial separately
[07:34:12] <scuzzy> I don't think it's ever been packed with QT
[07:34:18] <scuzzy> maybe I'm wrong, I dunno
[07:34:40] <RikusW> scuzzy: I stripped it down to make it smaller, only included the actual source
[07:35:04] <RikusW> I have my own Rtk/Rcom lib too, but had some sync problems with it :(
[07:35:06] <scuzzy> mkay
[07:35:09] <RikusW> will fix that later
[07:35:28] <RikusW> and it doesn't enumerate the ports yet...
[07:35:43] <scuzzy> I did something when I worked for nokia
[07:35:52] <scuzzy> to identify which serial ports where attached to dev boards
[07:36:05] <scuzzy> I can't remember exactly how I did it
[07:36:13] <scuzzy> but, I looked for names on USB devices
[07:36:22] <scuzzy> and then discovered which serial ports were attached to those usb devices
[07:36:29] <RikusW> qext does include the enum source
[07:36:30] <scuzzy> so, we were using omap 3430 devboards...
[07:36:40] <DanFrederiksen> hmm changing to atmega88 it didn't know the variable TIMSK
[07:36:42] <scuzzy> I used the windows FC to do it
[07:37:16] <RikusW> FC ?
[07:37:19] <RikusW> CE ?
[07:37:26] <scuzzy> Foundation Classes
[07:37:32] <inflex> DanFrederiksen: yes, there's some register name changes
[07:37:34] <RikusW> MFC ?
[07:37:39] <inflex> DanFrederiksen: eg, they'll become like TIMSK0
[07:37:39] <scuzzy> yeah
[07:37:46] <scuzzy> anyway
[07:38:00] <scuzzy> sorry, it wasn't for seial ports
[07:38:02] <inflex> hola scuzzy - hoegaan dit?
[07:38:12] <scuzzy> it was to establish which storage device was the dev board
[07:38:23] <scuzzy> I think it spat out a drive number
[07:38:25] <RikusW> scuzzy: seems I only have to do the flash + eeprom RW code now
[07:38:30] <scuzzy> inflex: dit gaan goed
[07:38:31] <RikusW> the rest seems finished
[07:38:41] <scuzzy> RikusW: nice, I'll give it a run tonight
[07:38:50] <scuzzy> inflex: en jouself?
[07:38:53] <RikusW> inflex: since when do you understand afrikaans ?
[07:39:21] <inflex> scuzzy: ja, so so ek se.
[07:39:33] <inflex> RikusW: ek kan nie Afrikaans praat nie :(
[07:39:38] <DanFrederiksen> the debugging in avrstudio 5, is that simulated? or somehow connected to hardware?
[07:39:52] <scuzzy> RikusW: hey kan, mar kak afrikaans
[07:39:57] <scuzzy> *hy
[07:39:59] <RikusW> inflex: maar jy kan dit darem tik ? :)
[07:40:16] <RikusW> DanFrederiksen: both, depending on you settings
[07:40:30] <RikusW> you'll need a jtagice or dragon to do real HW debug
[07:40:39] <DanFrederiksen> RikusW, any good reason why atmega8, 16 or 32 doesn't have debugging?
[07:40:44] <DanFrederiksen> in avr studio
[07:40:52] <DanFrederiksen> or did they go full retard
[07:41:25] <inflex> DanFrederiksen: they're and old chip
[07:41:27] <RikusW> DanFrederiksen: m16 and 32 support jtag
[07:41:38] <RikusW> m8 don't have On Chip Debug at all
[07:41:45] <inflex> RikusW: see, I get lost on some words
[07:41:56] <inflex> RikusW: I worked in Gauteng area for 4 years
[07:42:07] <DanFrederiksen> I don't need on chip debug though
[07:42:13] <RikusW> inflex: how long ago ?
[07:42:24] <inflex> RikusW: back starting in '96
[07:42:42] <DanFrederiksen> inflex, but aren't they still used? what else if not atmega8?
[07:43:05] <RikusW> DanFrederiksen:
http://sites.google.com/site/megau2s/home/jtag use a m8 to build a jtagice mki for use with AS4
[07:43:07] <inflex> DanFrederiksen: sure, there's a lot of stock of them still out there - they're made still for legacy replacements or such
[07:43:23] <inflex> DanFrederiksen: but it's an ancient chip and the mega48/88/168/328 is the preferred replacement
[07:43:45] <inflex> they're also rather power-hungry compared to the new ones
[07:43:59] <DanFrederiksen> now you pack of bastards tell me :)
[07:44:19] <scuzzy> bastards?
[07:44:23] <inflex> DanFrederiksen: hah, it's on the datasheets/specs "Not recommended for new designs"
[07:44:25] <DanFrederiksen> are they pin and hex code compatible?
[07:44:36] <inflex> DanFrederiksen: pin - yes, hexcode, probably not
[07:44:37] <RikusW> pin yes
[07:44:50] <scuzzy> I happen to prefer... infamous super villans
[07:45:43] <RikusW> scuzzy: like heroes Sylar ? or Teabags ?
[07:45:45] <inflex> I remember when I wastrying to do a wildlife tracking device that had to last 12 months... with the mega8 it was just not going to happen... but then the mega88 came along and it was a project saver :D
[07:46:19] <DanFrederiksen> none of the pdfs I have for it mentions anything about not being recommended
[07:46:45] <RikusW> maybe your pdfs is old too
[07:46:54] <scuzzy> RikusW: Uhhhhhh, yeah, sylar will do
[07:49:20] <DanFrederiksen> I just checked atmel's pages and pdf. not a word about being not recommended for new designs
[07:49:40] <inflex> Looks like I was dreaming it - swear I saw it somewhere
[07:49:54] <DanFrederiksen> np
[07:50:08] <DanFrederiksen> do you guys use studio 5?
[07:50:17] <DanFrederiksen> I guess I could just install 4
[07:50:25] <DanFrederiksen> iirc it has debug for 8
[07:50:28] * tlvb uses avrgcc
[07:50:41] <DanFrederiksen> bunch of nix commies :)
[07:50:46] <tlvb> hehe
[07:51:23] <DanFrederiksen> does it support debug?
[07:52:02] <RikusW> yes
[07:52:16] <RikusW> build the jtagice mki clone on the link about
[07:52:18] <tlvb> I don't know, my debugging methods usually consists of outputting information the usart or toggling unused gpios
[07:52:23] <RikusW> then you can use it with m16 + m32
[07:52:31] <RikusW> *above
[07:53:32] <karlp> they don't get the "not reocmmended for new designs" until they're just about EOL.
[07:53:48] <karlp> doesn't mean there's not a similar part with better specs available that will eventually replace it .)
[07:55:10] <DanFrederiksen> if they don't intent to support it it would be nice to say so. I'm not mad. I'm disappointed :)
[07:55:15] <DanFrederiksen> intend
[07:56:11] <DanFrederiksen> I suppose next time I buy from digikey I can migrate to atmega88. if they support that one
[07:56:54] <inflex> DanFrederiksen: surprised they offer any debugging on the 8... since afaik it has no support for it any how - one of the big moans with people hacking into brushless speed controllers using it
[08:00:36] <DanFrederiksen> debugger seems to work with atmega88
[08:01:08] <DanFrederiksen> does avr studio 5 debugger offer some way to set input events for the chip?
[08:01:15] <DanFrederiksen> in simulation
[08:01:57] <DanFrederiksen> or do I just add code to fake it?
[08:02:10] <DanFrederiksen> or are you all nix pinkos? :)
[08:02:23] <DanFrederiksen> you know noooothing :)
[08:02:35] <RikusW> don't know AS5
[08:02:35] <DanFrederiksen> (old john cleese reference)
[08:02:44] <DanFrederiksen> ok
[08:02:50] <RikusW> AS4 provided a simple way to use a text file for that
[08:02:59] <DanFrederiksen> ok
[08:05:48] <RikusW> DanFrederiksen: ever used On Chip Debug ?
[08:05:52] <RikusW> like jtag ?
[08:14:21] <DanFrederiksen> RikusW, no. fairly noob to avr coding
[08:15:03] <DanFrederiksen> there is no bool in atmega? just use uint8?
[08:15:26] <inflex> There is bool now
[08:15:44] <inflex> at least in avr-gcc / libc
[08:16:09] <inflex> obviously they're still packing it into register/byte somewhere, but yes, there's a bool type
[08:16:28] <DanFrederiksen> hmm, avr studio doesn't seem to like bool or Bool
[08:16:41] <DanFrederiksen> do you assign it true or false? or 0 and 1
[08:17:50] <DanFrederiksen> maybe I need to include another header besides inttypes..
[08:18:10] <DanFrederiksen> nah should be standard
[08:18:21] <RikusW> or typedef uint8_t bool; ;)
[08:18:38] <DanFrederiksen> :)
[08:19:33] <DanFrederiksen> doesn't like true either
[08:19:36] <DanFrederiksen> ah well
[08:20:50] <RikusW> #define true 1
[08:29:28] <tlvb> -1
[08:36:55] <karlp> #include <stdbool.h> ...?
[09:05:45] <DanFrederiksen> karlp, yep worked. does that increase hex file size?
[09:06:05] <DanFrederiksen> hopefully not
[09:07:07] <soul-d> mmm lets see if sample-ling still works during crisis and get some free xmass pressent
[09:07:33] <DanFrederiksen> nah looks like filesize is unchanged
[09:07:53] <DanFrederiksen> crisis?
[09:10:58] <soul-d> world wide global economic thingy :P
[09:11:46] <soul-d> donno maxim been spaming my inbox enough can't blame me for wanting some of there chips ;)
[09:18:30] <karlp> you can look at stdbool.h and see, but if you ever have a toolchain that increases binary size by adding std headers, get a new toolchain.
[09:18:45] <karlp> stdbool.h is particularly small and compact :)
[09:42:31] <RikusW> hi scuzzy
[12:47:14] <RikusW> LUFA -> Law-Abiding Unregistered Firearms Association
[12:47:33] <RikusW> www.lufa.ca
[12:48:56] <RikusW> Lufa is a relative of Squash, Zucchini, cucumbers and gourds.
[12:50:07] <carp3> Why some people say that PIC is better for industrial/commercial products?
[12:51:35] <RikusW> more expensive than avr...
[12:52:31] <Steffanx> That's also not 100% true
[12:52:39] <carp3> what about stability/reliability ?
[12:53:04] <Steffanx> I think microchip is a better company/manufacturer ..
[12:53:13] <Steffanx> (i don't talk about the products they make)
[12:53:42] <RikusW> why ?
[12:54:20] <Steffanx> You remember the big stock issues of atmel a while ago?
[12:54:25] <Steffanx> That sucked *ss
[13:01:40] <carp3> >I< think AVR is good for hobby only not for real projects. don't know why. Maybe because i didn't see any AVR is commercial projects...
[13:01:49] <carp3> s/is/in
[13:02:32] <RikusW> pic is good for hobbyists...
[13:02:35] <Steffanx> I don't see a good reason either
[13:02:45] <RikusW> that was what it was intended for
[13:03:13] <Steffanx> If you say so
[13:03:24] <karlp> how many products do you pull apart? _really_ ?
[13:03:42] <carp3> 40-50... maybe
[13:03:47] <Steffanx> Every product I can .. karlp
[13:03:53] <specing> I've have so far seen two projects with PICs and 0 with AVR
[13:04:53] <RikusW> I've seen pic inside toyota remotes
[13:05:02] <RikusW> and the receiver too
[13:05:41] <Steffanx> I never see products with AVR's either. Some products have other chips from Atmel though
[13:05:46] <Steffanx> flash, eeprom etc.
[13:06:47] <RikusW> don't xbox controllers have m16u2 ?
[13:07:10] <Steffanx> To hack then.. o no that's a play station :)
[13:07:28] * RikusW is downloading lufa 111009
[13:07:39] <Steffanx> ok
[13:07:50] <Steffanx> This isn't twitter RikusW ..
[13:08:10] <RikusW> weird LUFACDC bootloader works in XP but not in linux....
[13:08:33] <RikusW> it enumerates as ttyACM0 but give io error....
[13:10:56] <karlp> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=84522&start=0&postdays=0&postorder=asc has a few others...
[13:11:30] <RikusW> http://www.urbandictionary.com/define.php?term=Lufa
[13:15:09] <carp3> heh:in forum posts-> "When you are stopped at a red light, do you disassemble it to check the MCU? "
[13:15:47] <carp3> actually i did, it was 8051 (Atmel) :d
[15:53:06] <moe3> hi
[15:53:40] <moe3> I am using AVR Studio 5 and AVR/GCC compiler. How can I find out what compiler version i have?
[15:54:29] <specing> gcc --version
[16:12:03] <moe3> @specing: THX
[21:18:00] <devcoder> hey everyone
[21:18:07] <devcoder> how goes it
[21:45:01] <k-man> is avrstudio free?
[21:45:11] <Tom_itx> yes
[21:45:19] <Tom_itx> mostly
[21:45:32] <Tom_itx> you gotta give em your firstborn and register with them
[21:45:42] <k-man> oh
[21:45:51] <k-man> ok, thanks Tom_itx
[21:45:51] <Tom_itx> i suggest studio 4 over 5 though
[21:45:59] <k-man> oh, that is interesting, why?
[21:46:07] <Tom_itx> buggy and bloated
[21:57:48] <k-man> ok, thanks
[21:58:55] <Tom_itx> iirc it's up to sp3
[22:48:11] * inflex really needs a bench meter in each of his workshops
[22:48:16] <inflex> sick of always having to cart the one meter around
[22:48:43] <Tom_itx> make one big shop
[22:53:12] <Casper> does anyone know of a good smps IC in thru-hole that isn't too complex to use and actually work well?
[22:53:20] <Casper> and have current limiting capability?
[22:59:48] <ziph> For what inputs and outputs?
