#avr | Logs for 2014-05-24

Back
[05:29:10] <ub|k> it's impossible. i'll just go buy a xtal
[05:30:48] <megal0maniac> ub|k: That's probably a good idea anyway :)
[05:31:57] <ub|k> megal0maniac: what's the advised frequency for an ATMEGA32 16PU ?
[05:31:59] <ub|k> 16 MHz?
[05:32:42] <megal0maniac> Yip
[05:33:11] <ub|k> i remember having read somewhere that they had some issues when running at their maximum frequency
[05:33:25] <ub|k> can't remember where, though
[05:34:05] <megal0maniac> If that was a hardware issue, it would have been fixed in the later revisions, or Atmel would have changed the spec. I wouldn't worry
[06:27:42] <bitd> Anyone know what the kind of wire is called you use with a function generator?
[06:51:38] <Lambda_Aurigae> bitd, connecting wire?
[06:51:43] <Lambda_Aurigae> probe?
[06:52:05] <Lambda_Aurigae> although, a probe would be more specific to a meter or oscilloscope really.
[07:03:02] <antto> http://i.imgur.com/qM28Nkg.png am i doing it right?
[07:03:20] <Lambda_Aurigae> that all depends on what you are trying to do.
[07:04:01] <antto> trying to make this software scope look less "software"
[07:04:57] <Lambda_Aurigae> well, the traces have a lot of digital artifacts in them but other than that, ok, I guess, as I haven't seen the before picture.
[07:07:36] <antto> well, this is an earlier pic: http://i.imgur.com/gJbzvXf.png
[07:08:05] <antto> the artefacts are due to overexposure
[07:17:08] <malinus> Lambda_Aurigae, which scope are you using?
[07:17:16] <malinus> *antto
[07:17:56] <antto> it's my own scope
[07:18:15] <antto> i have some questions about the trigger "HOLD" behaviour
[07:19:20] <malinus> antto, using a avr?
[07:19:25] <antto> nonono
[07:19:44] <malinus> what then?
[07:19:57] <antto> this is more like a "soundcard scope"
[07:20:07] <Lambda_Aurigae> I don't have a scope myself.
[07:20:07] <antto> but i'll try to make it less lousy ;]
[07:20:22] <malinus> antto, what is the range of it?
[07:21:17] <Lambda_Aurigae> I have a homemade modified logic shrimp though.
[07:21:24] <antto> well, there are some of the knobs visible: http://i.imgur.com/zekHmHs.png
[07:22:10] <antto> my question is.. if you got a signal which crosses the trigger level many many times (think of a high-freq sine wave or white noise or so) ...
[07:23:05] <antto> if the HOLD is at zero - then i guess the timebase will retrigger very soon, so you won't get any trace on most of the right-side of the screen
[07:23:09] <antto> is that true?
[07:25:49] <antto> i mean like this: http://i.imgur.com/WYmx7al.png ... the top signal is the trigger source
[07:26:37] <antto> if i used the bottom signal - it would retrigger even more often, thus it will be even shorter than that
[07:29:19] <Lambda_Aurigae> too early in the morning for me to think on that.
[07:30:23] <antto> ;]
[07:30:38] <antto> need someone familiar with old CRT scopes
[07:34:49] <Lambda_Aurigae> my old scope didn't have a trigger hold feature.
[07:34:51] <Lambda_Aurigae> just a trigger.
[07:35:11] <Lambda_Aurigae> and it would complete a full sweep before retriggering
[07:35:23] <Lambda_Aurigae> so if the trigger was faster than the sweep it wouldn't trigger that fast.
[07:36:51] <antto> yeah, so in your case, the horizontal signal generator ignores the trigger source while it's "on screen" and only accepts retriggering after it has reached past the end of the screen
[07:37:08] <Lambda_Aurigae> yeah.
[07:37:23] <Lambda_Aurigae> it was an old heathkit scope.
[07:38:28] <antto> the HOLD adjustment adjusts how long the scope should ignore retriggering, but what are the exact ranges and such - that's what i wanna know, can't find an answer ;]
[07:38:47] <Lambda_Aurigae> look at manuals for other scopes.
[11:29:07] <ambro718> Hey, does someone understand how these special cases in PWM work (atmega2560)? " The extreme values for the OCRnx Register represents special cases when generating a PWM waveform output in the fast PWM mode. If the OCRnx is set equal to BOTTOM (0x0000) the output will be a narrow spike for each TOP+1 timer clock cycle. Setting the OCRnx equal to TOP will result in a constant high or low output (depending on the polarity of the output set by the
[11:29:08] <ambro718> COMnx1:0 bits)
[11:29:15] <ambro718> How do I achieve duty factor TOP/(TOP+1) (almost always on, but off at the last clock period) I suspect it could be that "narrow spike" it's talking about but that sentance is vague to me.
[11:33:38] <Tom_itx> ambro718, have you read dean's articles on timers and pwm?
[11:34:02] <ambro718> no, I don't know what you're referring to
[11:34:37] <Tom_itx> i will enlighten you then
[11:34:57] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/abcminiuser/articles/avr_timers_index.php
[11:35:24] <Tom_itx> pwm toward the bottom
[11:35:45] <Tom_itx> but you should start at the top
[11:38:26] <ambro718> Tom_itx: I don't see anything in the PWM section here that answers my question
[11:38:56] <Tom_itx> maybe the spike is too narrow to see
[11:39:33] <Tom_itx> one clock period isn't much to measure
[11:40:27] <ambro718> I don't care about the spike, I want to know how to achieve TOP/(TOP+1) duty cycle. In some other uC's, I would just set "OCR" to TOP, but in this AVR chip TOP is a special case.
[11:41:12] <Tom_itx> not sure
[11:56:14] <ambro718> the way I see it, it's not possible due to this special case for OCR=TOP. If it wasn't a special case it would work, though it would make it impossible to achieve 100% duty cycle only when TOP=0xFFFF.
[11:56:25] <ambro718> that's how it is on the Atmel ARMs
[11:56:52] <ambro718> or some other ARM
[13:26:09] <umquant_> is eclipse with the AVR plugin still the only AVR capable IDE for linux?
[13:26:41] <Tom_itx> i dunno but i think it's horrible
[13:28:24] * hjohnson does most of his AVR development under xcode :P
[13:28:39] <umquant_> I agree
[13:28:50] <malinus> umquant_, there is also the arduino IDE
[13:29:00] <umquant_> eh not a fan either.
[13:29:12] <umquant_> I am just sick of Makefiles lol
[13:29:15] <malinus> umquant_, don't worry, you will move away from using IDE's soon enough, and embracing the power of emacs/vim instead.
[13:29:26] <hjohnson> heh
[13:29:27] <malinus> :)
[13:29:41] <umquant_> is that what you use?
[13:29:47] <hjohnson> well, in the end, that's all that I'm doing, but the code completion under xcode is nice
[13:29:55] <hjohnson> (once you pull a few tricks to make it parse the header files)
[13:30:28] <umquant_> gotcha
[13:30:44] <hjohnson> protip: don't start writing code until you finalize your hardware.
[13:30:57] <umquant_> I am having a bitch of a time with Makefiles linking various parts of this application
[13:31:18] <hjohnson> actually, no, I take that back... writing the code before I build the hardware has helped me find a couple of hardware goofs
[13:32:08] <hjohnson> on a completely unrelated note... since I have a PPS signal on my board (eminating from the GPS module) should I wire that to the atmel just because?
[13:32:10] <malinus> umquant_, yes I use emacs. for everything from web-development, to playing with the kernel, writing pyhton script and sending love letters :)
[13:32:25] <malinus> and also avr development obviously ;P
[13:32:33] <hjohnson> malinus: I know that EMACS is a reasonable user environment, but have they fixed the lack of a text editor yet? ;)
[13:32:36] * hjohnson hides
[13:32:38] <umquant_> Do you use any makefile generation tools?
[13:32:54] <malinus> hjohnson, yeah emacs is a great os ;)
[13:32:54] <hjohnson> umquant_: I just start with a skeleton makefile and edit it by hand.
[13:33:24] <umquant_> gotcha. I have used an IDE and just recently started using makefiles (templates). Looks like I just need to learn some more about them
[13:33:31] <malinus> umquant_, use the so popular avr-makefile that floats everywhere on the net. And edit to your use. It even has avr-dude flashing in it etc.
[13:33:45] <hjohnson> yeah, that's bascially what I use
[13:33:51] <umquant_> yup. Having trouble linking to other directories currently.
[13:33:59] <umquant_> Just need to play with it some more
[13:34:06] <hjohnson> ahh, all my code is in single level
[13:34:29] <umquant_> Yea I am splitting up the library code, and then all the different examples
[13:34:31] <hjohnson> (I'm also using FreeRTOS and some ASF shit... though I may ditch the ASF shit since it's massive and doesn't gain me much)
[13:34:48] <malinus> hjohnson, even when using usb-stacks etc.?
[13:34:57] <malinus> lufa and whatnot
[13:35:00] <hjohnson> FreeRTOS has some nifty stuff in it though for the kind of stuff I'm doing yet
[13:35:07] <hjohnson> malinus: haven't started to integrate any USB stuff yet
[13:35:30] <hjohnson> malinus: the problem I have with LUFA is that as I recall, it's not interrupt driven so I don't know how well it would work in my situation.
[13:35:43] <hjohnson> (I'm running some seriously multi-threaded code on my xmega)
[13:36:40] <hjohnson> http://www.exar.com/common/content/document.ashx?id=239 I'm running one of these badboys as well
[13:38:02] <malinus> hjohnson, the aviable usb stacks for the xmega should be interrupt driven, since they should use the peripheral. If you however use something like a attiny or atmega without the usb peripheral (using v-usb), then I'm not sure.
[13:38:57] <hjohnson> malinus: iirc, the last time I looked at LUFA it was polled (but using the peripheral)
[13:39:18] <malinus> ew
[13:39:26] <hjohnson> yeah
[13:39:29] <malinus> call dave
[13:39:36] <hjohnson> I've got the USB hooked up, but it's not my focus yet
[13:39:45] <hjohnson> my main focus is shovling and parsing strings around. :)
[13:40:06] <hjohnson> (I'm building an NMEA multiplexer/router for my boat)
[13:40:15] <malinus> hjohnson, what about using the good old serial for that?
[13:40:23] <hjohnson> malinus: well, all of that is serial
[13:40:38] <hjohnson> but I also have USB connected in case I want to use it
[13:40:59] <hjohnson> most of the time, a computer will connect to it via wifi (provided by one of those wifly modules)
[13:41:12] <hjohnson> and just get the NMEA data dumped over a TCP socket
[13:42:38] <malinus> you can also use VGA for communication
[13:42:41] <malinus> at least one-way
[13:42:53] <malinus> it might however interrupt what you see on the screen ;)
[13:43:33] <malinus> have anyone thought of this before? VGA for pc->mcu communication, not sure the 20mhz avrs would be fast enough though.
[13:43:52] <hjohnson> lol
[13:44:07] <hjohnson> well, you could use the DDC pin, which is just I2C ;)
[13:44:34] <malinus> I don't know the VGA at all
[13:46:15] <hjohnson> way way back in the day, I had to drive a VGA display from an Altera FPGA
[13:46:21] <hjohnson> timing was a bitch, but doable
[13:46:37] <hjohnson> http://gerblook.org/pcb/imgmxHk2oBxBy6QPXSVKBB there's my current board layout
[13:54:47] <umquant_> If my lib is in foobar/lib and my example / makefile is in foobar/examples/exampleOne would the include argument for my makefile be "INCDIR = -I../../lib"
[13:58:13] <hjohnson> not sure, sorry
[13:59:47] <umquant_> /join #linux
[16:06:28] <ambro718> Regarding PWM, how do I go from a non-zero duty to a zero duty, and then back, without glitches? Setting OCR=0 will not result in zero duty per documentation. So I'm thinking, to do to zero duty, I can set PORT for the pin to 0 and then COM0A1:COM0A0=0 to stop the OC unit from defining the pin output. But then how do I go back to nonzero duty?
[16:06:30] <ambro718> If I just change OCR0A then set COM0A1:COM0A0=2 to set the OC unit back to "non-inverted PWM", I suspect that the pin may glitch by immediately going high until the first compare match or overflow.
[16:08:54] <ambro718> that is if the OC output happened to be high last time it was changed. The pin may remain high until the next overflow, which may be far longer than what the new OCR (duty cycle) dictates.
[16:12:18] <ambro718> Or does the hardware continuously update the pin output in PWM mode, as opposed to just setting/clearing it on overflow/match?
[17:04:37] <hjohnson> hrmm.. how good is the onboard RTC oscillator on an xmega?
[17:50:10] <Tom_itx> hjohnson, pretty good i'm told
[22:52:30] <Casper> rue_more: how strong is 1" emt tube?
[22:55:20] <Casper> basically I need to make a X under a fountain so I can attach some steel ropes to prevent kids from flipping it over... planning to put some bars under the (prefab) concrete slab (the 16x16x1" kind), then connect the ropes to the X... the fountain is about 5' wide
[22:55:36] <Casper> I wonder if 1" is big enought
[22:56:30] <Casper> if it fall on a kid, it's death... if it fall on an adult, it will most likelly be ER...
[22:58:03] <Casper> concrete base, weight like 60-70lbs... then a kind of bowl sit on it, must be about 150lbs... easy to tip by itself... then another base of about 50lbs sit in it, then the figurine of like 100lbs...
[22:58:11] <Casper> tip the bowl, and the figurine fall
[23:04:15] <LoRez> a single long pipe straight down if it goes through the fountain base a while would work too
[23:04:26] <LoRez> fsvo long
[23:09:03] <Casper> I just need something that will not rot in... let's say... 10 years, and won't bent or get out of the ground...
[23:09:58] <Casper> might actually aim for 3 pipes (so 6 ends) and do 3 wires loop instead of 4... might actually be stronger...
[23:10:07] <Casper> it's round with some petals...
[23:10:13] <Casper> I think it's 7 petals..
[23:12:12] <Casper> ow well, will go tomorrow to see if it will work... or if I find a better idea for cheaper :D
[23:12:39] <LoRez> you want to dig up that much to lay something like that in the ground?
[23:12:40] <Tom_itx> the conduit edge will cut the rope anyway
[23:13:33] <Tom_itx> or it will all rust out before then
[23:13:37] <Casper> Tom_itx: steel rope, and will put some hook there anyway
[23:13:43] <Casper> and won't pass inside the pipe
[23:13:59] <Tom_itx> use rebar then
[23:14:44] <Casper> that is actually what my uncle suggested, but I do not know if the store have some big enought...
[23:14:49] <Casper> never seen them...
[23:15:10] <Tom_itx> steal some from a bridge construction site
[23:15:21] <Tom_itx> it'll be coated too
[23:16:42] <Casper> so you mean I need to wait until the Champlain bridge fall, then wait more years until they start the construction? :'(
[23:16:43] <Tom_itx> i put a hook in a corner of the drive to lock my camper to
[23:16:51] <Tom_itx> yeah
[23:17:16] <Casper> that bridge is in very bad shape, there is talk about possibly being forced to disallow trucks from passing on
[23:17:32] <Tom_itx> those steel girder bridges built in the 60's & 70's will start falling soon
[23:17:35] <Casper> it's the bridge with the most trafic in canada...
[23:17:44] <Casper> ... and the federal refuse to pay for it
[23:17:56] <Tom_itx> they're using it for population control
[23:18:07] <Tom_itx> waiting till it falls in rush hour traffic
[23:18:10] <Casper> few years ago, during an inspection, they found some of the cables to be broken
[23:18:29] <Casper> when they simulated that... the bridge collapsed (in simulation)
[23:18:39] <Tom_itx> since that one fell up north in the US they've been fixing alot of ours
[23:18:44] <Casper> so... they don't understand why the bridge is still standing
[23:19:14] <Tom_itx> we've got one here in town they limited traffic to the center 2 lanes and no trucks allowed
[23:19:25] <LoRez> yikes
[23:19:26] <Tom_itx> i feel really safe crossing that one
[23:19:29] <Casper> bridges are under federal juridictions... but the federal say this one fall under the province juridiction...
[23:19:36] <Tom_itx> it's being replaced currently
[23:19:57] <Tom_itx> LoRez, on broadway HWY81
[23:20:07] <Casper> they are planning to replace it, but at the bare minimum, it will take 10 years before the construction start
[23:20:20] <Tom_itx> the original I-35
[23:23:53] <Tom_itx> use SS with SS cable
[23:26:58] <Casper> I don't know if it's SS, but the one outside hasn'T rusted in a year, which include winter...
[23:27:09] <Casper> the bird feeder that it hold however... did rust...
[23:35:33] <Tom_itx> screw anchors would also work
[23:35:44] <Tom_itx> buried or not
[23:41:07] <Casper> yeah, but I'm worried that they don't work well... it's a matter of kid safety