Back
[00:03:45] <nevdull> well i think there's the load from the resistor and led which is minimal
[00:04:41] <nevdull> you could also try a local decoupling capacitor between the leads from each DT
[00:04:54] <jadew> I think I know what's the issue
[00:05:16] <jadew> I also have a pullup resistor in there (connected to the red led - which is turned on directly by the switch)
[00:05:33] <jadew> this resistor is then connected to one of the pins, telling me the output is turned on
[00:05:40] <jadew> now... that pin is the other AREF pin :(
[00:06:06] <jadew> I don't use that one, but it seems it's affecting the readings
[00:06:13] <nevdull> the local decoupling cap i used on mine to reduce the high freq impedance seen by the load on my DTs looking back toward the PSU.
[00:06:23] <nevdull> then there's always the feared ground loop :)
[00:06:38] <nevdull> hmm
[00:07:07] <nevdull> i usually set all AREF to the same volt ref or use the internal voltage reference
[00:07:25] <jadew> now that seems like a good idea
[00:08:29] <jadew> I guess I'll have to cut that trace and do just that
[00:08:56] <nevdull> my common design idiom is a 10uH inductor on the AVCC, 100nF isolated caps to ground on all VCC, and a single stabilized voltage ref
[00:09:34] <jadew> I have decoupling caps too on AVCC
[00:09:54] <jadew> don't have the inductor tho :)
[00:10:36] <nevdull> may not need it, but it's there to smooth out the possible jitter and ripple on the analog voltage supply *if* i'm using adc. if not, i just bypass/decouple with 0.1uF
[00:12:49] <jadew> deffinitely something to keep in mind for the future
[00:13:09] <jadew> well, I'm gonna cut the trace and see what happens, brb
[00:13:19] <nevdull> alrighty...good luck :)
[00:13:27] <jadew> thanks :)
[00:20:14] <jadew> bingo
[00:20:19] <jadew> the result doesn't changes anymore
[00:20:41] <jadew> gonna connect that thing to the same reference (thanks for that tip)
[00:20:44] <langoliers> hi
[00:20:49] <jadew> hi langoliers
[00:20:58] <nevdull> awesome, jadew!
[00:21:01] <nevdull> congrats
[00:21:11] <jadew> thanks
[00:21:21] <langoliers> how do you protect your microcontroller from transient overvoltage if they have 6.0V absolute maximum voltage range, and want to run it from 5V power ?
[00:21:38] <langoliers> the 5V TVS diode peaks at 6.7V!
[00:23:27] <nevdull> crowbar?
[00:25:32] <langoliers> and maximum clamping voltage: 9.2V
[00:25:48] <langoliers> ;/
[00:26:36] <nevdull> well, for the tvs i suppose it matters whether you're trying to protect against positive or negative voltage stress
[00:27:24] <nevdull> i'd think signal voltage would be stable between 0V and the tvs reverse breakdown voltage
[00:28:08] <langoliers> i want to protect the power line from lightning bolts, 230VAC or something (users)
[00:29:10] <nevdull> well, you can choose between your tvs clamp type or go with a crowbar type
[00:29:31] <langoliers> will your crowbar suppress a 1ps 60A pulse ?
[00:29:47] <nevdull> depends whether you want to clamp the voltage at a defined voltage potential during an overvoltage event or whether you can handle a short circuit to ground in the case of overvoltage
[00:30:26] <nevdull> i dunno. could look into various thyristors
[00:30:34] <langoliers> hahah ok...
[00:31:17] <langoliers> i'm sure very much thyristors can switch on in 1ps
[00:31:28] <nevdull> or possibly using the tvs clamp in reverse bias direction
[00:31:52] <nevdull> that would allow it to push a considerable amount of power dissipation
[00:32:16] <langoliers> or use a 100W led right?
[00:33:22] <nevdull> clear blue if possible
[01:29:18] <langoliers> OndraSter__<= now i know ps2 keyboard only requires 16kHz clock so it will be fine in C
[02:13:57] <rue_bed> its synchronous, clock rate dosn't matter
[03:43:39] <megal0maniac> zlog
[03:48:02] <megal0maniac> Bloody router
[03:49:33] <OndraSter__> who did you kill with it?
[03:50:49] <megal0maniac> Nobody, yet...
[03:51:18] <megal0maniac> I need some kind of persistent logging. Or 12V UPS. Or both
[03:51:52] <megal0maniac> Or I need to learn for my digital systems test tomorrow. Can't decide
[03:52:35] <specing> http://1wt.eu/articles/alix-ups/
[03:55:57] <megal0maniac> I have 12V transformer and 12V battery.. :/
[03:56:04] <megal0maniac> This looks nice:
http://www.mini-box.com/picoUPS-100-12V-DC-micro-UPS-system-battery-backup-system
[03:56:07] <megal0maniac> But expensive
[04:01:09] <megal0maniac> This might work better
http://www.circuitstoday.com/wp-content/uploads/2009/05/simple-ups-circuit.jpg
[04:01:47] <megal0maniac> Just take out the transformer (because I already have 12V) and the 5V can be used as additional USB power
[04:04:54] <OndraSter__> I thought this would be both in & out stage
[04:17:30] <specing> That circuit is so inefficient it makes my head hurt.
[04:34:48] <megal0maniac> I shall not use it :)
[04:47:55] <specing> I mean... dropping 12V to 5V linearly wastes >60% energy
[05:27:08] <nevdull> don't you dissipate the same amount of energy whether you do it linearly or really fast switching or step-down?
[05:30:07] <theBear> not even close if you do it right
[05:31:07] <theBear> a good switcher (depending on topology) is usually between about 80 and 95% efficient regardless of how far it is converting up or down, a linear gets linearly worse in ratio with the load
[05:32:36] <nevdull> i'm not talking about transduction or energy lost to heat or electromechanically...P = IV and i you drop from 20V to 5V, regardless of whether you're offside switching or doing naive linear drop, you still have to dissipate the same amount of energy don;'t you?
[05:32:54] <theBear> and wow, that circuit is pretty damned rough, and even tho i had a lot to drink today and not much sleep, i'm sure the redundant diode is gonna make something behave silly
[05:33:13] <nevdull> hey if one diode is good then two must be great
[05:35:45] <theBear> no you don't, basically an inductor works like a spring... and you might know that stretching a spring and releasing it makes a TINY bit of heat from friction etc, and an inductor is the same, but because it's springy you never have to dissipate more than the inefficiencies of it and your switching transition speed... if a switch is only EVER on OR off, there's no dissipation, it's only when you try to put a switch 'half on' like in a linear reg that you
[05:35:45] <theBear> get big dissipation
[05:36:46] <nevdull> yes, but a spring also converts mechanical energy to potential energy. the inductor is respondign to induced current through the E-field
[05:36:56] <theBear> say you want to turn 100v into 1v... you can do linear and dissipate 99% of your total power for a 1% desired load, or you can turn on 100% power for 1% of the time, and 0% power for 99% of the time, so long as you got something to deal with the averaging
[05:37:23] <theBear> the inductor is storing energy in itself, then reabsorbing and releasing it, kinda like taking turns being either side of a transformer
[05:37:36] <nevdull> i mean, i wholly agree that switching is much better than plain ol' linear drop, since you lose the drop voltage then have to dissipate pretty much the difference of Vin and Vout as heat
[05:37:39] <theBear> go to wikipedia, they got pictures and stuff
[05:38:03] <nevdull> yeah, i've read a lot about inductors. LC circuits still get the better of me.
[05:38:14] <theBear> no pretty much, with linear it's exactly that PLUS losses due to imperfect components... with switching it's ONLY losses due to imperfect components
[05:39:06] <nevdull> but if you drop 20V to 5V don't you dissipate 15V * I in both cases? it's just how/where it's dissipated? maybe i'm missing a major clue here.
[05:43:06] <theBear> no ! like i said, you can EITHER dissipate 3/4 of it like an old fashioned dude (linear) OR you can just supply the full power for 1/4 of the time
[05:44:09] <theBear> say you carrying a bowling ball around with you ... you can take the full weight of it all the time, or you can attach a spring to it and just give it a good quick pull everytime it almost hits the ground, then forget about it while it springs up and eventually falls back down
[05:44:17] <theBear> finally, i thought up a real world analogy !
[05:44:20] <theBear> not a practical one, but a real one
[05:44:33] <nevdull> that was a good analogy, thanks :)
[05:44:40] <theBear> hooray !
[05:46:48] <nevdull> thanks theBear for your patience in explaining that to me
[05:55:58] <theBear> hehe, not patience, just drunken persistance... back hurts today, so i do just about anything to avoid leaving this chair :)
[06:02:45] <nevdull> haha
[06:03:20] <nevdull> sorry to hear about your back...back pain is a reall beeyatch
[07:35:26] <kdehl> Afternoon.
[07:36:39] <Horologium> morning.
[07:38:07] <kdehl> Hehe.
[07:38:25] <kdehl> So, what piece of software can I use to connect to a serial port?
[07:38:28] <kdehl> Just telnet?
[07:38:48] <kdehl> No, that's only for TCP/IP. Heh.
[07:38:54] <Horologium> what OS?
[07:39:03] <kdehl> Linux
[07:39:09] <Horologium> minicom
[07:39:10] <Horologium> kermit
[07:39:11] <kdehl> I tried minicom, but I have no idea wheter it works.
[07:39:13] <kdehl> Heh. Okay.
[07:39:18] <kdehl> minicom -b 9600 -D /dev/ttyUSB0 -o
[07:39:22] <kdehl> Does that look a-ight?
[07:39:56] <kdehl> I set the baud rate to 9600 (or so I think).
[07:40:44] <Horologium> http://www.vanemery.com/Linux/Serial/serial-console.html
[07:40:46] <kdehl> I do have a ttyUSB0 that appears when I add the USB-to-serial device.
[07:40:56] <kdehl> Oh.
[07:41:06] <Horologium> that looks right but not sure off the top.
[07:41:23] <Horologium> that link shows how to setup the serial port and connect it to your active console/terminal.
[07:41:28] <Horologium> a no-frills way.
[07:41:45] <RikusW> kdehl: ^a o
[07:41:53] <RikusW> that will get you into the options menu iirc
[07:41:57] <Horologium> although it goes all kinds of wierd down bottom.
[07:42:04] <RikusW> ^a q will quit
[07:42:13] <RikusW> or was it ^a z
[07:42:20] <Horologium> and
[07:42:22] <Horologium> screen /dev/ttyUSB0 115200
[07:42:29] <Horologium> super simple way.
[07:42:49] <Horologium> http://bec-systems.com/site/859/the-easy-way-to-get-serial-terminal-in-linux
[07:43:05] <kdehl> Heh. screen's the shit.
[07:43:12] <RikusW> win7 even eliminated hyperterm :S
[07:45:24] <kdehl> That Linux serial console howto seems to be for connecting _to_ the Linux host. I want it the other way around.
[07:46:06] <kdehl> But anyway, as I understand it there's no more hardware setup than the options that you give to screen or minicom, is there?
[07:46:35] <kdehl> Like do I have to configure the hardware somehow, to set up the baud rate, stop and parity bits?
[07:46:43] <kdehl> On the Linux host, that is.
[07:47:06] <RikusW> only minicom itself
[07:47:09] <kdehl> Right.
[07:47:12] <kdehl> Good.
[07:47:25] <kdehl> Then I have eliminated that problem. Then the problem is on the controller itself.
[07:47:29] <RikusW> press ctrl-a then release ctrl and press o
[07:47:29] <kdehl> I think.
[07:47:37] <RikusW> inside minicom
[07:48:08] <Horologium> for windows, use tera term pro..it is old, no longer developed I think, but it works.
[07:48:49] <kdehl> I use Linux, but thanks anyway.
[07:49:05] <kdehl> Oh, minicom, I thought you meant screen. Heh.
[07:49:14] <kdehl> Yeah, no, minicom seems to be setup correctly.
[07:49:16] <Horologium> kdehl, this is why I like having 2 serial ports and a crossover cable...can test my serial connect at the computer then work outward.
[07:49:45] <Horologium> RikusW mentioned windows up there a few minutes ago...that's why I mentioned tera term pro.
[07:50:15] * RikusW also prefer using Linux :)
[07:50:49] <kdehl> Horologium: Good idea.
[07:51:09] <kdehl> Damn. minicom inside of screen. Not the best plan.
[07:51:15] <kdehl> Oh well, worked out.
[07:51:28] <Horologium> one can even, if you like to play, use one serial port to listen in on another.
[07:51:53] <kdehl> That's what I thought you meant.
[07:52:08] <nevdull> i use minicom or serialport on linux, but i wrote a dumb terminal specifically for interfacing with AVRs in C# for windows that also has an embedded tcp/ip server that will proxy internet connections to your USB-connected avr
[07:52:22] <Horologium> can tie the rx line of one serial port to the rx or tx line of the other and use it to listen in on one side of the serial conversation.
[07:53:25] <kdehl> Yeah.
[07:53:56] <kdehl> I used those a lot before the time of the internets.
[07:54:29] <Horologium> if you just want to watch what is coming in the serial port you don't even really need a terminal emulator...just cat /dev/ttyUSB0
[07:54:57] <kdehl> Aha. I tried that too, but I wasn't certain it worked that way.
[07:55:03] <Horologium> does here.
[07:55:18] <kdehl> But then I need to setup the baud rate and stuff first, right?
[07:55:23] <Horologium> you can cat file.txt > /dev/ttyUSB0
[07:55:36] <kdehl> Ah, cool.
[07:55:40] <Horologium> and send the file named file.txt out the serial link.
[07:56:28] <Horologium> you can even cat a harddrive...to and from...but that can cause serious problems if you write raw data to a harddrive that way.
[07:56:44] <Horologium> also dd can be used to copy the output from a serial port to somewhere.
[07:57:13] <Horologium> with dd you can tell it to only pull so many bytes then stop.
[07:57:14] <kdehl> Right.
[07:57:27] <kdehl> But what abuot the baud rate and stop bits and stuff then?
[07:58:21] <Horologium> use stty
[07:58:29] <kdehl> Ahokay.
[07:58:34] <nevdull> maybe set with stty
[07:58:38] <Horologium> or setserial
[07:58:46] <nevdull> doh, horo is the faster typer here :)
[07:58:46] <kdehl> But I think I'll just start with minicom.
[07:59:17] <kdehl> Hmhm, there's something wrong with the AVR then.
[07:59:22] * kdehl goes rubber ducking
[07:59:36] <nevdull> you may have to sudo to grab the port if you haven't xdev'd it
[08:00:38] <Horologium> nevdull, 70 to 75 wpm last typing test...which was about 5 years ago.
[08:01:14] <nevdull> lol that's speedy. last i tested i was in the 60's but i made a lot of errors
[08:01:45] <nevdull> i spend more time on the <backspace> key, depending on which monitor i'm looking at and how contorted i've become typing on the keyboard heh
[08:02:17] <Horologium> I have a tendency to type while watching the tv or talking to the wife or something.
[08:02:45] <Horologium> can't type for crap on those split ergo keyboards.
[08:02:47] <nevdull> oh yah me too...i totally go autopilot
[08:03:06] <kdehl> TXD0 on the controller goes straight to TXD on the serial port, and RXD0 to RXD, right?
[08:03:20] <kdehl> So no switching cables or anything else weird.
[08:03:30] <nevdull> me neither, which is why my last project was building an avr-based Sparc Type 5 keyboard converter for those lovely type5 sparc keyboards that i oh so much like and adore
[08:04:08] <Horologium> kdehl, ummmm....no.
[08:04:22] <Horologium> transmit on one side goes to receive on the other...and versa visa..
[08:04:52] <Horologium> just like if you make a loopback....connect tx to rx on the serial port...
[08:05:24] <Horologium> and do you have a level converter between the microcontroller and the serial port?
[08:05:33] <nevdull> if you're using a max232 do: TX0 -> T1IN -> T1OUT -> RS232 Pin 2
[08:05:35] <Horologium> something like a max232 chip?
[08:05:41] <kdehl> Horologium: Haha. I just discovered that. Now it works! Thank you!
[08:05:45] <Horologium> welcome.
[08:05:57] <nevdull> and RX0 to R1OUT -> R1IN -> RS232 PIN3
[08:06:03] <Horologium> it's not like SPI where you connect miso to miso and so on.
[08:06:05] <kdehl> Horologium: No, no level converter.
[08:06:13] <kdehl> TTL all the way.
[08:06:23] <Horologium> oh, your usb adapter is ttl level then?
[08:06:41] <kdehl> Yeah.
[08:06:46] <Horologium> that helps.
[08:07:09] <kdehl> Yup. I bought both versions, will test the true rs-232 one I get the cable.
[08:07:34] <kdehl> Those Chinese might take some time delivering stuff, but for less than a dollar I can wait.
[08:07:35] <Horologium> definitely don't forget that level converter....otherwise you can cause damage to the microcontroller.
[08:07:48] <kdehl> Absolutely.
[08:08:24] <nevdull> you can run it into a non-inverting hex buffer powered at your target voltage level for quick/easy level convert
[08:08:34] <Horologium> nevdull, was it you I was talking to yesterday about those RF avr units?
[08:08:38] <kdehl> Horologium: I'm using this one:
[08:08:39] <kdehl> http://www.ebay.com/itm/251082091781?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
[08:08:42] <nevdull> Horo: yep
[08:08:59] <Horologium> nevdull, ok....did some more digging and it is definitely a 2 chip package.
[08:09:13] <nevdull> i've been working on the atmel public zigbee network stack all morning
[08:09:30] <nevdull> horo: are they on the same die? or how does that work?
[08:09:31] <Horologium> you get the atmega1284p or atmega644p, depending on which one you want, and the RF chip is separate and connects to the SPI port.
[08:09:44] <nevdull> oh you mean as in external?
[08:09:46] <Horologium> the package is 2 separate chips.
[08:09:50] <nevdull> oh wow
[08:09:51] <Horologium> yes, external.
[08:10:02] <nevdull> i never would have guessed that
[08:10:03] <Horologium> the rf chip is a quad flat no lead package.
[08:10:13] <nevdull> yeah like a QFN32 or something
[08:10:14] <Horologium> which means, a royal bitch to solder.
[08:10:18] <Horologium> yeah.
[08:10:23] <Horologium> something like that.
[08:10:36] <nevdull> not so bad if it has solder over the lips but some of them only have on the bottom so i have to break out my solder paste and reflow it in the oven heh
[08:11:49] <nevdull> so i think it's odd that they would use different nomenclature (ie atmega*RF/RZ etc) when they are clearly two separae entities.
[08:11:54] <nevdull> kinda misleading
[08:12:14] <Horologium> http://www.digikey.com/product-detail/en/AT86RF230-ZU/AT86RF230-ZU-ND/1553508?WT.mc_id=PLA_1553508&gclid=CMbHp4jOuLYCFYxaMgodR2kAaA
[08:12:21] <Horologium> yeah, qfn32
[08:12:36] <Horologium> it is a kit..
[08:12:41] <nevdull> yah i bought two at86rf232's. staying away fromt he 231's
[08:13:05] <Horologium> MCU Wireless chipset for IEEE 802.15.4 and ZigBeeŽ applications. It is a bundle of the Atmel AVR ATmega1284P and Atmel AT86RF230 radio in the worldwide 2.4GHz frequency band.
[08:13:18] <Horologium> "bundle"
[08:14:18] <nevdull> they got my undies in a bundle with that less-than-forthcoming revelation about their clear and separate chips.
[08:14:32] <nevdull> although they may redeem themselves if their zigbee pro modules are of any merit
[08:14:51] <nevdull> they're a bit more spendy though than the $3.50 at86RF23* transceivers
[08:16:44] <Horologium> hmm...wonder if schmartboard has a qfn32 board.
[08:17:12] <Horologium> they DO!
[08:17:22] <Horologium> 10 bucks
[08:17:27] <Horologium> but, that's about normal.
[08:17:33] <Horologium> http://www.schmartboard.com/index.asp?page=products_csp&id=76
[08:17:36] <Horologium> those I can solder.
[08:17:46] <Horologium> just put chip on and heat it up.
[08:17:56] <Horologium> raised ridges between pads with solder already on the pads.
[08:18:48] <nevdull> yah that's nice
[08:20:01] <nevdull> i can etch down to qfn32 and upwards to about TQFP100 with photoresist etching but have a harder time with the toner transfer method when i'm making 0.012 traces
[08:20:20] <nevdull> i usually scour ebay for breakout boards when i want a fast and dirty prototype of an smd component
[08:21:22] <nevdull> and ebay has several nice socketed breakout boards. i thinik i paid $5 for an SOIC8 socket to 8PDIP so i just slap in an attiny45, program it, then take it out and solder it somewhere else
[08:21:45] <Horologium> might have to look for those.
[08:22:20] <nevdull> they're well worth it but the prices go up exponentially as the number of pins increase on the socket
[08:23:11] <nevdull> i'd love to get a TQFP64 one so i could program my xmegas without having to solder them to a breakout board and plug them into my programmer/dev board but they are super spendy
[08:24:37] <Horologium> I bet.
[08:30:11] <kdehl> Have you guys tried those cheap Chinese HC-05 bluetooth modules?
[08:30:30] <Horologium> not me, but, I haven't done much with bluetooth beyond my handsfree headset.
[08:30:38] <kdehl> Heh. Okay.
[08:31:39] <kdehl> It's supposed to be configurable with AT commands, so I figured I should be able to connect it to the serial module which in turned is connected to the computer. Then I tried to connect to it with minicom, but nothing seems to happen...
[08:31:43] <Horologium> can't justify it as I have a pile of nrlf24 modules here.
[08:34:14] <kdehl> Hm. Maybe the AT commands work in the other direction, so to speak. You have to connect to it over bluetooth first, then you use AT commands.
[08:34:37] <kdehl> Nah, screw it for now.
[08:44:04] <kdehl> Okay, this is weird. I can only cat /dev/ttyUSB0 when I have minicom connected to the same port!
[08:44:50] <nevdull> did you start minicom with sudo?
[08:45:02] <theBear> it's been a while, might need setserial or something to set it to a sane mode when minicom isn't
[08:45:12] <Horologium> yeah....setserial will activate it.
[08:45:42] <Horologium> or stty but that's a bit more complex to use I think.
[08:45:42] <nevdull> yah, and hang up nicely in minicom (like ^X or something)
[08:46:10] <nevdull> i got crufty ports when i just quit out of minicom without reseting it beforehand
[08:47:11] <kdehl> No, minicom works just fine. But I can't do 'cat /dev/ttyUSB0' unless minicom is running. And when I do run cat when minicom is also running, cat takes over (most of) the input from minicom. But when I close minicom, the cat command dies as well.
[08:48:03] <Horologium> use setserial before the cat.
[08:48:10] <Horologium> without minicom.
[08:48:14] <langoliers> hii :)
[08:48:28] <langoliers> Horologium<= xfce :)
[08:49:19] <Horologium> what about it?
[08:49:33] <langoliers> kde is a huge junk, gnome is better, but still..., xfce was written in C and optimized, it is fast and stable
[08:49:46] <Horologium> that's what I'm running...
[08:49:52] <langoliers> kk
[08:50:02] <theBear> wtf does that have to do with cmdline stuff ?
[08:50:31] <theBear> what we're talking about was the same long before xfce was even thought of
[08:50:52] <Horologium> theBear, think it was a continuation of yesterday's conversation...
[08:51:02] <Horologium> where I switched off of opensuse and back to debian
[08:51:07] <langoliers> i was just reading back
[08:51:20] <theBear> ahh, i aint been around much recently
[08:51:39] <langoliers> theBear got lost in the woods
[08:51:43] <Horologium> on another note...I have a dozen chickens on my front porch and my cat is having a fit.
[08:51:47] <theBear> tho i was thinking thismorning i hadn't heard the name langolier for a long time... always kinda rolled off the tongue, damned good book as a kid too
[08:52:07] <theBear> poor kitty, if it wasn't fitting it'd have a great time chasing them chickens round the porch :)
[08:52:15] <Horologium> she is inside only cat.
[08:52:38] <Horologium> last time she got out she tangled with the rooster on the front porch and came back inside like she had been shot out of a cannon.
[08:52:43] <nevdull> sounds like you're having a "fowl" time
[08:52:49] <nevdull> *bad a ching*
[09:08:15] <DrLuke> Hi, is there any easy way to store ints in program space?
[09:08:44] <DrLuke> const int __inttan[] PROGMEM = {...} only results in the lower byte being deposited in program space
[09:09:05] <seldon> Use pgm_read_word instead of pgm_read_byte to read it back.
[09:09:35] <kdehl> Hm. It doesn't seem to be possible to use setserial to change the baud rate on USB serial devices.
[09:09:39] <kdehl> Crappy.
[09:10:16] <DrLuke> seldon: thanks!
[09:19:58] <GuShH> megal0maniac_afk: to charge a 12v SLA you need 13.8VDC for a float charge.
[09:20:41] <GuShH> anything over 13.8 will be discarded as heat and in turn higher hydrogen content.
[09:23:02] <Horologium> kdehl, what about stty ??
[09:23:51] <Horologium> DrLuke, are you trying to store them during runtime?
[09:24:00] <DrLuke> Horologium: no
[09:24:03] <DrLuke> http://pastebin.com/Fnqq9Zai
[09:24:22] <Horologium> then just define some constants or define your variable with a start value maybe?
[09:24:45] <Horologium> aahh...
[09:24:58] <DrLuke> this works a treat :)
[09:25:06] <DrLuke> and I shouldn't run out of program space any time soon
[09:25:31] <DrLuke> only 17.5% are taken up so far
[09:28:18] <kdehl> Horologium: Didn't seem to work either. But it's fine, I really don't need it. I can use minicom.
[09:56:16] <microchip_sac> does anyone know a good place to learn pwm using avrs?
[10:00:07] <specing> microchip_sac: datasheet?
[10:02:10] <kdehl> That's never a good introduction.
[10:02:34] <kdehl> microchip_sac:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=68302&start=all&postdays=0&postorder=asc
[10:02:47] <kdehl> That's a start.
[10:03:31] <kdehl> He's usually very good at explaining things for someone without prior knowledge on the subject.
[10:07:01] <qubyte> hi, I want to create a DMX communication working with my atmega8. I'm an absolute newbie. What component should I use? Should SN75176B be okay?
[10:08:02] <Horologium> qubyte, do you want the avr sending or receiving DMX signals?
[10:08:22] <Horologium> that chip should work for the rs485 level converter.
[10:14:25] <[z_z]> wow. So the reason form my frustration these past few days... was debug vs release selected in avrstudio... one more reason why i can't stand IDEs
[10:14:48] <kdehl> Um. I can't get minicom to _send_ data from the keyboard. screen works just fine in both directions, but minicom only receives data.
[10:16:17] <kdehl> I can turn on local echoing, but that doesn't solve anything. But it does look better. Heh.
[10:17:00] <qubyte> Horologium: i want to receive dmx signals form pc. I also send them but just from avr to avr.
[10:21:21] <tzanger> kdehl: Do you have hardware flow control disabled in minicom?
[10:21:31] <Horologium> qubyte,
http://sourceforge.net/projects/avrdmx/
[10:21:49] <Horologium> http://avrdmx.sourceforge.net/ better link
[10:22:20] <kdehl> tzanger: Ah, yes. I had.
[10:22:28] <kdehl> tzanger: What is that anyway?
[10:22:38] <kdehl> Nvm, I can google it. :)
[10:23:02] <qubyte> Horologium: thanks
[10:23:18] <Horologium> qubyte, welcome. that was the first hit in google search for avr dmx
[10:23:40] <kdehl> tzanger: No, I don't get it. What is it? :)
[10:23:55] <tzanger> Hardware flow control = don't send unless CTS is active
[10:24:29] <kdehl> Ahaa.
[10:24:57] <kdehl> Those old-school pins that haven't been used since the days of modems?
[10:25:05] <Horologium> yes.
[10:25:14] <kdehl> Interesting.
[10:25:21] <tzanger> They're still used in modern hardware
[10:25:23] <Horologium> which are also used for things like ardweeny reset line and serial port avr programmers.
[10:25:25] <kdehl> Oh.
[10:25:28] <qubyte> Horologium: I stumbled across this project before, but I thought it is just about the software? I just wanted to be sure that i can use the chip I mentoined above :)
[10:25:45] <Horologium> qubyte, I suggest learning about rs485 then.
[10:25:59] <Horologium> yes, that chip you mentioned is an rs485 level converter.
[10:26:26] <kdehl> I see.
[10:26:28] <kdehl> Well.
[10:26:46] <kdehl> I don't use it, apparently, for I only use two pins.
[10:28:57] <Horologium> http://llg.cubic.org/dmx4linux/avrdmx.html there is a hardware implementation
[10:29:04] <Horologium> but it isn't quite what you are looking for.
[10:30:13] <Viper7> qubyte: i do lots of work with DMX, i have a bunch of SN75176B's in my drawer, they're what you want :)
[10:30:25] <Viper7> and all you really need
[10:30:32] <tzanger> kdehl: three pins but yes, you don't use it
[10:31:02] <Viper7> those, preferably a 100 ohm load/termination resistor, and some wires :P
[10:31:12] <Viper7> and basically any microcontroller on the market
[10:31:37] <tzanger> 100 ohms? that seems an odd termination for RS485
[10:31:40] <kdehl> tzanger: True that.
[10:32:27] <Viper7> might be 120?
[10:32:40] <Viper7> yeah it is
[10:33:11] <Viper7> 100 ohms is used tho
[10:33:18] <Viper7> just not correctly :P
[10:33:51] <tzanger> yeah it's not super critical for most applications
[10:34:34] <kdehl> Heh. Yeah.
[10:36:57] <qubyte> Viper7: ok thanks
[10:39:50] <amee2k> .... what in fucks name is the ISR() constant in avr-gcc for the "TIMER1 CAPT
[10:39:57] <amee2k> " interrupt on a mega8a?!
[10:40:22] <OndraSter_> datasheet does not know?
[10:40:43] <amee2k> the datasheet says "TIMER1 CAPT" but "TIM1_CAPT_vect" doesn't work
[10:40:48] <tzanger> amee2k: I usually grep the AVR include file directory
[10:41:05] <amee2k> it throws a warning, compiles, and the just resets whenever an interrupt fires
[10:41:34] <amee2k> misspelling a variable name is a compiler error, i don't get why misspelling an interrupt handler name is not >_<
[10:43:19] <seldon> ISR(foo) expands to void foo(void) __attribute__((something_or_other)), I believe. It makes sense that a compiler would accept a function with a nonsensical attribute.
[10:44:06] <amee2k> well, it can apparently detect that an interrupt name is invalid because it throws a warning
[10:44:40] <amee2k> is there a use case that requires defining invalid interrupts? or why is it a warning and not an error?
[10:44:42] <seldon> Well, yes. It can't figure out where to put that thing in the interrupt table. It could throw an error, but a warning is a defensible choice.
[10:45:53] <seldon> Someone might tamper with the interrupt table manually, for example. It's not the compiler's place to prevent that.
[10:46:05] <amee2k> because i spent about an hour wondering why the ponies my controller kept randomly resetting
[10:46:26] <amee2k> because the warning scrolled out at the top of my terminal window in the make output
[10:46:28] <seldon> Take it as a lesson to heed the compiler's warnings.
[10:46:45] <amee2k> avrdude produces a lot of output immediately after the compile run
[10:47:23] <seldon> Use -Werror, then.
[10:48:29] <amee2k> okay, apparently there are a lot of definitions for TIM1_CAPT_vect in /usr/lib/avr/include/avr/*.h
[10:49:30] <amee2k> ...... only for the mega8 it is spelled out as TIMER1 instead of TIM1 >_<
[10:50:32] <amee2k> tzanger: thanks for the hint. found it in the include file
[10:52:47] <tzanger> Excellent. I've always found the docs lacking or out of date
[10:55:29] <amee2k> tzanger: thats what docs usually are, yes :>
[10:55:53] <amee2k> if you never actually use your own shit, writing docs is just too... mundane apparently
[10:58:14] <tzanger> Not really, but its difficult to keep in sync with code changing quickly
[10:58:39] <tzanger> The pressure is always on getting it working
[11:27:42] <amee2k> i still don't get how that possibly does NOT result in a compiler error at SOME point
[11:28:22] <amee2k> isn't it supposed to expand the interrupt name into an IVT index at some point?
[11:28:59] <amee2k> so it can, well, set up the interrupt handler :)
[11:33:06] <langoliers> termination resistance used to be 100 ohm, for cat5e
[11:33:26] <langoliers> ( or split 2x50 ohm )
[11:33:42] <langoliers> this is matched to the cable impedance
[11:37:06] <seldon> amee2k, imagine I want to do something like this:
http://codepad.org/4Ioia00s
[11:37:56] <seldon> Well, that's a pretty minimal example. Imagine I want to store the interrupt handler address somewhere at runtime. I'm not arguing that this is often a sensible idea, but it's not up to the compiler to prevent you from doing that sort of thing.
[11:40:58] <amee2k> mmh we could make an INVALID_ISR macro :>
[11:41:24] <seldon> Or the compiler could just warn when it thinks you're being silly but still do what you demand of it.
[11:41:45] <amee2k> how common of a use case is that, actually?
[11:42:13] <amee2k> i mean, if you really want to you can always make a code example that depends on any behavior you want
[11:42:45] <seldon> Which is why the compiler should default to doing what you tell it to and not standing in your way.
[11:42:52] <seldon> There's always -Werror.
[11:43:38] <amee2k> still, how commonly do people actually use that?
[11:44:57] <seldon> Probably not often. But when you want to do that sort of thing and the compiler just tells you "no," that's rather more aggravating than having to read your compiler's warnings.
[11:45:32] <amee2k> i don't really see that being an exceedingly common thing, so the obscure-but-possibly-correct case should be an error by default IMO
[11:46:21] <seldon> It's a good thing you don't write compilers, then. Just use -Werror if you want the compiler tell you what to do rather than the other way around.
[11:46:39] <amee2k> :>
[11:47:01] <amee2k> my definition of warning was more like obscure-but-possibly-incorrect
[11:47:57] <amee2k> "opt-out" and "opt-in" both give you either option, but they are not equivalent
[11:48:06] <amee2k> marketing departments have realized that a long time ago :>
[11:48:34] <Horologium> so fix it.
[11:48:57] <amee2k> ....
[11:49:05] <amee2k> thats what she said too
[11:49:23] <Horologium> rather than complaining that it doesn't work the way you like it, fix it.
[11:50:07] <tzanger> langoliers: Ethernet is still 100 ohm. Rs485 is usually 120
[11:50:33] <amee2k> assuming you know what you're talking about, we both know the "its open source, you can fix/implement it yourself" line is a bad joke
[11:50:35] <rue_bed> I liked the borland compiler, it would tell you exactly where you screwed up, not a location 4 files later cause you forgot to close a {
[11:51:12] <Horologium> back in the day borland was awesome.
[11:52:09] <Horologium> I was using borland C compiler back in the early to mid 90s.
[11:53:04] <amee2k> i learned my first C on borland C lol
[11:53:26] <Horologium> learned mine on whatever compiler system V release III had.
[11:54:07] <amee2k> borland turbo c++ 3 i think, but i only used it for normal C
[11:57:19] <tzanger> Horologium: You sure about that? I've used Borland, Microsoft (quickc and msvc) ccs, and various other embedded compilers... They are all pretty bad about that
[11:57:36] <tzanger> llvm is actually the best out of the bunch
[11:57:52] <Horologium> this was nearly 20 years ago.
[11:58:16] <tzanger> I started on quickc, had Borland, won watcom c++, then largely stuck with bcc
[11:58:25] <tzanger> Err gcc
[11:58:25] <Horologium> back then the compilers were rather,,,militant.
[11:58:31] <tzanger> Stupid autocorrect
[11:58:40] <langoliers> i use this time gcc -o "%e" "%f" -Wall -O3 -malign-double -Wstrict-aliasing=1 -masm=intel -msse2 -msse3 -mtune=native -mfpmath=sse -mno-push-args -lrt $(sdl-config --cflags --libs)
[11:59:08] <tzanger> They're still pretty bad :-)
[12:00:03] <langoliers> and it is nice sometimes to read the asm output gcc -o "%e.asm" "%f" -S -Wall -O3 -malign-double -Wstrict-aliasing=1 -masm=intel -msse2 -msse3 -mtune=native -mfpmath=sse -mno-push-args -lrt $(sdl-config --cflags --libs); less "%e.asm"
[12:02:17] <tzanger> I can't remember now whether I started with turbo c or quickc. Now I think I started with Borland but moved over to quickc
[12:03:17] <langoliers> the sphinx C-- was a good ASM macronizer concept
[12:05:16] <langoliers> Horologium<= btw if you ground every second conductor in a flat cable cross-talk will be reduced by at least 80dB i believe
[12:05:31] <Horologium> yeah, so?
[12:05:44] <tzanger> I'd bought b.lo.c for PIC. What a waste
[12:06:31] <langoliers> so no capacitors are needed in the programmer, and it will not crosstalk... you switch data and it will not clock with it
[12:08:17] <langoliers> 19pf/20cm between neighbor conductors can cause problems
[12:37:21] <_abc_> Hello. Can someone explain how exactly one can switch timer prescalers without triggering an interrupt? I read the datasheet 3 times and it is not clear. Does the prescaler issue an output when overflowing, or when going to zero?
[12:37:30] <_abc_> target is atmega8a
[12:38:36] <Tom_itx> turn interrupts off before you do it?
[12:38:57] <_abc_> I intend to switch prescalers inside an ISR
[12:39:07] <_abc_> triggered by one of the timers.
[12:39:35] <_abc_> Paragraph 15.3 is quite befuddled imho. Maybe I am tired.
[12:41:36] <OndraSter__> disable the interrupt, switch, enable interrupt?
[12:41:51] <_abc_> The way I see it, to change prescalers without nuking the other timer, I need to: a) change the prescaler for the current timer in its overflow isr b) set some flags so the next timer interrupt on that timer will be ignored c) exit the isr and expect the next trip to be caused by an irregular timed interrupt due to the switch d) ignore this inside the isr and reset the flags so the next trip will be 'good'.
[12:42:01] <_abc_> OndraSter__: inside isr it will be disabled, yes?
[12:42:04] <qubyte> Hi,
http://pastebin.com/U9zm8UNV , I'm trying to control an LED via Hterm (setting 0/1, a Terminal Tool) but It doesn't work. The code should be correct but I never used Hterm before. So i might use it wrong, there isn't any documentation. I connect to my device, choose hex on the input and send 00 or FF. How can I test if my ar really received the byte?
[12:42:24] <_abc_> also the switching causes uncertainty which needs to be addressed, so the next time it trips may be rather random.
[12:42:49] <_abc_> So I am looking at a state machine thing, right?
[12:42:56] <_abc_> Or is there a cleaner way?
[12:43:30] <_abc_> I can't reset the prescaler as the other timer will be running off of it
[12:43:44] <_abc_> Ideas?
[12:44:04] <_abc_> note: I am using timer1 in capture mode and timer0 as a tick clock for display refresh and the like
[12:44:40] <OndraSter__> _abc_, holy crap man, so much stuff you wrote
[12:44:55] <_abc_> heh thanks ^^
[12:45:01] * _abc_ blushes
[12:45:09] <_abc_> not for real
[12:45:37] <_abc_> Seriously, I have to do some state machine gym to work around the funny interrupt just after I switch the prescaler, right?
[12:45:54] <_abc_> And there is no other way to do this. Right?
[12:47:09] <_abc_> Another one: with prescaler :8 and 1MHz clock, if I do a capture and then reset TCNT1 and leave the ISR in C, it will take way more than 8 cycles, right?
[12:47:30] <_abc_> with :1 clock more so.
[12:47:54] <_abc_> Is there a way to fudge this? Add a constant to the captured timer to fix this?
[12:47:57] <seldon> which chip are you using?
[12:48:02] <_abc_> atmega8a
[12:48:11] <_abc_> programmed in C using gcc
[12:48:27] <_abc_> I was thinking of declaring the isr naked
[12:48:59] <_abc_> just to get more control over some uncontrollable variables such as latency in isr service
[12:49:09] <seldon> mega....so you'll need three clocks to get into the ISR, four for the reti, and at least two to fiddle with TCNT1. Yes, it'll take longer than 8 clocks.
[12:49:17] <seldon> Even naked.
[12:49:22] <_abc_> yes, I thought so
[12:49:35] <_abc_> As long as the delay is constant, +/-1 clk it's okay
[12:49:40] <_abc_> even +/-2
[12:49:47] <_abc_> but there is no way to avoid that, right?
[12:49:49] <seldon> Do you just want to set TCNT1 = 0?
[12:50:51] <_abc_> I do something like ISR( *OVF* ) { if(!SomeGlobalFlag) { GlobalVar16 = ICR1; GlobalFlag = 1; } TCNT1 = 0; }
[12:51:15] <_abc_> where the global access is expensive on gcc, it does all sorts of munging, I looked at the assembly.
[12:51:37] <_abc_> I could do an inline asm isr I think.
[12:51:48] <_abc_> Just to get the timing under control.
[12:52:39] <_abc_> I filter out captures under 60 counts anyway, for other reasons, so very short captures are not going to cause a problem anyway.
[12:54:01] <_abc_> I guess I'll just look at the asm output and add a fudge factor to the output as needed.
[12:54:23] <_abc_> To compensate for latency. I can do that in the main code.
[12:54:30] <seldon> Well, there's no way to get the whole ISR to run in 8 clocks or less, since you lose seven just for jumping to it and leaving again. But the timing-critical part is just after TCNT1 = 0, isn't it?
[12:55:34] <_abc_> There is no timing critical part, really. I just don't want errors to creep in.
[12:56:00] <_abc_> Assuming I am running at prescaler:1 there may be say up to 15 cycles added before I sample ICR
[12:56:11] <_abc_> so I need to substract those as a constant
[12:56:22] <_abc_> If I run at :8 I might need to substract one or two
[12:56:27] <_abc_> At 64, likely 0.
[12:56:50] <_abc_> So All I need to do is, make a table of constants to substract in the main code.
[12:57:45] <_abc_> Also since I will be switching prescalers in main somewhere, not in isr, as it looks, I will have to set up some state machine to ignore the GlobalFlag once after each prescaler change, since it will be unpredictable.
[12:59:06] <_abc_> Hm, okay, looks clear to me.
[12:59:12] <_abc_> So far.
[12:59:28] <_abc_> Is there an atmega with a 32 bit counter and capture capability?
[12:59:36] <Horologium> no.
[12:59:48] <_abc_> not even the large ones?
[13:00:06] <Horologium> not sure about the xmega chips but I know none of the mega chips have 32bit counters.
[13:00:18] <_abc_> okay, thanks
[13:00:25] <_abc_> not even 24 bit?
[13:00:31] <_abc_> 16 bit is a little puny for many apps
[13:00:57] <Horologium> not even 24 bit.
[13:01:02] <_abc_> ok
[13:01:11] <_abc_> I think arms have 32 bit counters
[13:01:19] <_abc_> But this app calls for a tiny mcu
[13:04:55] <Horologium> there are small arms.
[13:07:13] <_abc_> yes, that is out of the question now
[13:12:16] <langoliers> the atmega168pa has 16 bit timer
[13:12:34] <langoliers> 65535 is crap ?
[13:12:49] <langoliers> i think you can use a byte to extend it to 24 bit
[13:13:53] <langoliers> or even more, just increment one at every overflow.
[13:14:48] <langoliers> maybe atmel should consider adding a 64 bit TSC in the avrs :)
[13:15:12] <langoliers> increment it with every clock cycle
[13:20:31] <rue_house> why dont people understand what 8 bit microcontrolers are for!?
[13:20:49] <Horologium> rue_house, dunno...
[13:20:53] <Tom_itx> counting to 8 and resetting?
[13:21:14] <Horologium> that's 3 bit processors
[13:22:49] <Tom_itx> but.. but.. there's only 8 bits..
[13:23:14] <Horologium> to count to 255!
[13:23:33] <Tom_itx> you can do that?
[13:23:43] <Horologium> with only 8 fingers even I can do that!
[13:24:34] <Horologium> and use my thumbs for carry and negative flags when doing binary math.
[13:26:48] <Casper> Horologium: so you can do signed 10 bits!
[13:27:13] <Horologium> I usually stick with unsigned 8bit...easier that way.
[13:27:29] <Horologium> my right thumb is mostly unused.
[13:34:50] <rue_house> on an avr you can do a long long, but I dont think even on a 64 bit machine can you do a long long long
[13:35:49] <Tom_itx> so get a cray for that
[13:41:02] <tzanger> Horologium: interesting idea with the thumbs
[13:41:03] <langoliers> they use bignum
[13:41:21] <Horologium> I didn't do it!
[13:41:32] <Horologium> but, yeah, it is how I was taught to do binary math.
[13:42:06] <Horologium> the original arm/thumb processor?
[13:43:28] <langoliers> this is a real arm :)
http://www.dfrobot.com/wiki/index.php?title=5-DOF_Robotic_Arm_(SKU:ROB0032)
[13:46:39] <langoliers> 5 DOF is needed for a good arm
[13:50:22] <_abc_> you can stop laughing eh
[13:50:41] <_abc_> Yes I can implement carry on overflow interrupt but that is beyond the point here I think.
[13:50:51] <_abc_> The project is ultra low cost and so on.
[13:53:48] <megal0maniac> GuShH: Got it, thanks :) Test week starts tomorrow so it'll be a while before I actually do something about it...
[13:54:17] <megal0maniac> Horologium:
https://sites.google.com/site/terminalbpp/
[14:01:55] <langoliers> do you use mobile phone displays for your atmega ?
[14:02:18] <langoliers> it is cheaper to get used old mobile phones than buying their displays lol
[14:02:39] <Horologium> I use 16x1 and 16x2 character LCD displays.
[14:02:51] <langoliers> hd44780 ?
[14:02:55] <Horologium> yup.
[14:03:20] <langoliers> and ain't using a nokia display cool ?:)
[14:03:31] <Horologium> would be if I had one and had a use for one.
[14:03:41] <rue_house> forget that, hook up a 20" lcd panel from a computer monitor!
[14:03:51] <langoliers> :)
[14:03:52] <Horologium> rue_house, that's my plan.
[14:04:08] <Horologium> vga output, 800x600 is the target.
[14:04:15] <rue_house> use a tiny13, and put windows 8 on it
[14:04:32] <Horologium> atmega1284p with linux be close enough?
[14:04:42] <rue_house> overclock the tiny13 to 4Ghz, and put 32G of ram on it
[14:05:22] <Horologium> I don't have a nitrogen cooling system handy.
[14:05:30] <rue_house> because every micrcontroller should be able to run windows just like any intel processor
[14:05:46] <rue_house> }:|
[14:05:48] <langoliers> Horologium<= that has only 44 pins ;/
[14:05:52] <Horologium> 40
[14:05:54] <langoliers> 32 ports
[14:05:56] <Horologium> I use dip package
[14:06:34] <Horologium> so?
[14:07:34] <rue_house> everyone knows that you need an operating system to turn a stepper motor, if your microcontroller cant run an operating system it must be useless right?
[14:07:47] <Horologium> zaktly
[14:09:00] <langoliers> http://www.nokia6100lcd.8m.com/
[14:09:01] <langoliers> :)
[14:23:11] <abcminiuser> SHOW ME THE EVIDENCE
[14:23:36] <Horologium> I keep asking the jehovas witnesses the same thing.
[14:23:41] <langoliers> http://www.youtube.com/watch?v=MgwdpLul59E
[14:24:00] <langoliers> http://www.youtube.com/watch?v=oep_eB51JPw
[14:24:41] <langoliers> avr scope
http://www.youtube.com/watch?v=05y4wFSBUT4
[14:26:04] <abcminiuser> https://www.youtube.com/watch?v=YFjoEgYOgRo
[14:26:08] <abcminiuser> So. Much. Stupid.
[14:31:17] <vsync_> ye well i'm not really too fond of dawkins either
[14:31:42] <vsync_> he's just a publicity whore populizer
[14:32:06] <langoliers> Analog clock demo using Sparkfun's Nokia 6100 LCD
http://www.youtube.com/watch?v=ICtPpbvPopY
[14:33:40] <Horologium> it's a simulated analog clock.
[14:46:20] <sabesto> abcminiuser: about the terminalwindow bug we discussed a week ago, just to make shure i'm not wrong
[14:46:45] <sabesto> sending \n\r or \r\n should produce the same result, right?
[14:47:03] <Horologium> depends on the terminal program.
[14:47:20] <sabesto> because \r\n works, \n\r doesnt, \n does the same as \r\n
[14:47:31] <sabesto> \r works
[14:47:54] <sabesto> in all cases the correct data shows up in hex view
[14:48:16] <Horologium> sounds like your terminal program treats each sequence differently.
[14:48:28] <sabesto> its the atmel studio plugin
[14:48:47] <Horologium> yeah, so, it treats each sequence differently.
[14:49:27] <sabesto> ive only used a few different terminal windows myself, like putty/screen
[14:50:02] <sabesto> never faced this problem, but if there are no standard to how it should work i dont know if its a bug or not :P
[14:50:34] <Horologium> try tera term or some other terminal program....
[14:50:44] <Horologium> or best yet, get an old vt100 terminal and try that.
[14:50:52] <sabesto> i thought \n was suppose to only change line ".\n" would produce a walking "." for instance
[14:51:29] <Horologium> any decent terminal program should let you set \n to just do newline or carriage return and newline.
[14:52:14] <sabesto> well, i use putty and got no problems with that, i just decided to try this plugin out. easier to use on 1 monitor setups
[14:52:15] <Horologium> as atmel studio 6 doesn't run on my computer for squat, I've never tried its terminal program, nor most of its functionality.
[14:56:17] <abcminiuser> sabesto, I think you're supposed to type directly into the lower send box to get newlines which you do with actual enters
[14:56:35] <abcminiuser> But either way, it should probably be an enhancement or bugfix
[14:58:00] <sabesto> this is recieved data
[14:58:25] <sabesto> from an xplained board to the computer
[15:02:15] <nevdull> do flat screen lcd monitors have 75ohm terminations on the vga rgb signals like plain ol crts?
[15:07:15] <_abc_> ahh the pros are on
[15:07:28] <_abc_> Is there a decent atmega sim under linux?
[15:07:33] <_abc_> for c code possibly?
[15:07:41] <_abc_> simulavr is slightly dated
[15:07:47] <_abc_> is anyone doing work on it?
[15:08:03] <langoliers> unix uses \n
[15:08:11] <langoliers> win uses \r\n
[15:08:12] <langoliers> :P
[15:08:42] <_abc_> losers use CR LF
[15:09:34] <sabesto> i dont know whats up, the more i test the more erratic stuff happens
[15:09:36] <_abc_> let me guess, % is not defined for unsigned long in C?
[15:11:36] <langoliers> http://en.wikipedia.org/wiki/Newline
[15:12:32] <langoliers> yeah it is stupid to cr
[15:12:56] <langoliers> i'd just step relative and pint in both directions
[15:13:08] <langoliers> print
[15:13:49] <langoliers> cr = idle seeking
[15:16:59] <sabesto> this is what i am talking about:
http://pastebin.com/1L19iJr1
[16:13:33] <langoliers> page304 says reset pin has internal 30-60k pullup resistor
http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf
[16:15:15] <langoliers> and io pins 20-50k
[16:25:21] <twnqx> hm. 1300 loc one week, no wonder i feel burned out a bit
[17:11:42] <pshaw> Hey, Is "Test Driven for Embeded C" by James W. Grenning worth reading? I am using avr-gcc and wan't do know tipps and tricks about using UnitTests in my projects.
[17:13:08] <Tom_itx> unittests?
[17:13:36] <Tom_itx> i don't put alot of faith in books except the K&R one
[17:14:04] <Steffanx> You're not fancy enough to use unit tests etc. Tom_itx :P
[17:15:48] <Tom_itx> are you?
[17:16:04] <pshaw> "The pragmatic programmer" series does a lot of good book for programmers. maybe i'll click it tonight but some eperients from a privious reader would be nice
[17:16:05] <Steffanx> Not on AVRs no
[17:17:14] <pshaw> i am using CU, but compile my code twice once with avr-gcc and for the tests with gcc. And i have a lot of nasty #defines in my code, that the tests should ne test, include, set, etc..
[17:17:43] <pshaw> this produces very confusding preprocessor hacks :-)
[17:17:56] <pshaw> i want to get rid of it and do it a better way
[22:22:16] <metalliqaz> quick, need to disable JTAG
[22:22:34] <metalliqaz> wish i wrote that down when tom threw that snippet up
[22:23:10] <Tom_itx> haha
[22:23:36] <metalliqaz> looks like JTD
[22:23:39] <metalliqaz> in MCUCR
[22:23:43] <Valen> //disable !@#$!# JTAG
[22:23:43] <Valen> MCUCR=(1<<JTD);
[22:23:43] <Valen> MCUCR=(1<<JTD);
[22:24:39] <metalliqaz> ah yes, i see it in the datasheet now
[22:24:45] <metalliqaz> gotta write it twice
[22:24:48] <Valen> i seem to recall doing it twice being important
[22:24:50] <Valen> yup
[22:24:53] <Tom_itx> yeah i just looked again
[22:25:37] <metalliqaz> feakin out over here, four lines dead
[22:26:03] <metalliqaz> well, not anymore, but for a second there...
[22:26:27] <tzanger> if there are other bits you need to maintain I'd recommend x = MCUCR | (1 << JTD); MCUCR = x; MCUCR = x;
[22:27:49] <metalliqaz> yep
[22:27:53] <metalliqaz> way ahead of you
[22:29:39] <Valen> tzanger: why?
[22:31:06] <metalliqaz> if you set other bits on that word to fiddle with interrupts, then you would destroy that data by just writing 1<<JTD)
[22:31:21] <Valen> fairy nuff
[22:32:11] <metalliqaz> alright... let's try this one more time, with feeling
[22:32:31] <Valen> ahh yes I see
[22:32:31] <Valen> i should presumably have |= not just =
[22:51:09] <R0b0t1> Atmel has xmegas with configurable logic blocks now.
[22:51:18] <R0b0t1> Mimicing those low-end pics, but on the higher end.
[22:56:11] <Valen> cpld?
[22:57:50] <R0b0t1> Not sure
[22:57:53] <R0b0t1> I think similar
[22:58:04] <R0b0t1> atxmegae32
[22:59:40] <R0b0t1> It does have higher-level components though, so I think they stuck a bunch of stuff on the die and hooked it up to a mux
[23:52:29] <jadew> hey guys, any idea why an xmega's ADC wouldn't read values up to Vref?
[23:52:45] <jadew> my Vref is 2.5 and it tops up at 2V
[23:53:59] <jadew> it also has a huge 0 offset
