Back
[03:18:17] <tld> EMI scares me. And I don't have a scope, so I can't check for accidental oscillations directly. It seems however, that "Check your work goddamnit!" is the golden rule when it comes to EMI. On the positive side, I have a radio, so I can check for actual emission, at least for frequencies (and harmonics) <1Ghz.
[03:19:15] <tld> I'm wondering though. If I keep track of clocks, swichmode-frequencies etc, and try to dampen those with a Pi-filter, using a ferrite-bead and two caps, checking frequency and DC-bias against graph for the bead, is there a good chance that might get me somewhere, or am I more likely to blow my foot off?
[03:20:41] <Richard_Cavell> Hi everyone. Is there any type of 8 -bit AVR more complex than the xmega planned for the future?
[03:20:47] <Richard_Cavell> Or do you have to go 32 bit to go more complex
[04:45:21] <The-Compiler> Heya! I'm fairly new to AVRs (did some stuff with MSP430 though) and I'm trying (with an ATmega 128) to run Timer 3 in CTC mode so PE4/OC3B gets toggled once in a while. Now I'm unsure where to write the compare value, since there is OCR3{A,B,C}
[04:50:23] <jacekowski> The-Compiler: it's all in the manual
[04:50:28] <jacekowski> The-Compiler: with examples
[04:50:46] <The-Compiler> jacekowski: "the manual"?
[04:51:12] <jacekowski> datasheet
[04:51:40] <The-Compiler> heh, haven't seen any examples in the datasheet yet
[04:51:44] <jacekowski> http://www.atmel.com/Images/doc2467.pdf
[04:52:35] <The-Compiler> yep, reading that
[04:52:38] <jacekowski> there is a lot of examples there
[04:52:48] <jacekowski> none for the OCR3 though
[04:53:15] <jacekowski> but if you look at interrupt vectors table
[04:53:18] <jacekowski> (table 23)
[04:53:35] <jacekowski> you'll see that there are 3 timer3 compare interrupts
[04:53:37] <jacekowski> A B and C
[04:57:46] <The-Compiler> yep
[04:59:30] <The-Compiler> from reading page 120 again ("Output Compare"
[04:59:34] <The-Compiler> oops
[04:59:56] <The-Compiler> from reading page 120 again ("Output Compare Units") I assume I need to set OCR3B for the output OC3B
[05:19:27] <RikusW> http://download.micron.com/pdf/datasheets/modules/ddr/DDA9C16_32_64x72AG.pdf
[05:19:30] <RikusW> DDR1 ds
[05:28:51] <The-Compiler> So I have
http://p.cmpl.cc/4951db75 now, but I don't have any frequency on PE4/OC3B and I have no idea why.
[05:39:19] <RikusW> seems it would be rather easy to design a dram pcb :-P
[05:54:58] <OndraSter_> of course it would
[05:54:59] <OndraSter_> well
[05:55:01] <OndraSter_> he is gone
[06:25:38] <tld> rotflmao, eBay has weird shit. "Inductor magic beads", axial throughholes… Sure, I'll just apply magic if I have EMI-issues, that'll work great. :)
[06:31:34] <Richard_Cavell> well I've heard of magic smoke
[06:33:01] <tld> true
[06:38:26] <OndraSter_> who let the smoke out
[06:38:29] <OndraSter_> huh hu hu hu
[06:41:01] <Horologium> someone please bomb OndraSter_'s house.
[06:41:31] <OndraSter_> :F
[06:41:36] <OndraSter_> is it now stuck in your head?
[06:43:32] <Horologium> nope.
[06:43:36] <OndraSter_> hmm
[06:43:40] <OndraSter_> I have to try harder :)
[06:43:42] <Horologium> fortunately for me I'm not a music type person.
[06:43:49] <Horologium> music doesn't stick in my head.
[06:43:59] <OndraSter_> oh
[09:44:54] <dardizer> just got the usb-com232-plus1 today, works perfectly fine with the stk500, even tested it on windows (because I wanted to try the new atmel studio, which sucks for the stk500 btw) and it works there too, native support on linux at /dev/ttyUSBX (most probably /dev/ttyUSB0)
[09:45:21] <xata> Hi
[09:45:38] <dardizer> hi Xata
[09:48:21] <xata> May be i am stupid, maybe this is a language barrier, but i can not get CTS and RTS signals. I want to connect atmega through ft232r and this have to be full-duplex connection. What are the modes for CTS/RTS when avr ready to recieve, when is not ready to recieve, when ready to send and when not ready to send?
[09:56:18] <Grievre> xata: Heh, there's actually two different ways that RTS/CTS are used
[09:58:03] <Grievre> xata: "CTS" means the same either way: You assert CTS when you are ready to receive data
[09:58:24] <Grievre> xata: but RTS can mean either that the serial connection wants to send to you, or that it's okay for you to send data to it
[10:09:38] <xata> Grievre: yes, thanks. i already found text in some black hole named "internet". in my native language i mean.
[10:09:59] <xata> looks like this will be a lot of !FUN!
[10:35:34] <xata> Grievre: If i want to get data, do what i have to and send it again - i have to set RXEN in UCSRB, read data, unset it, do what i have, set TXEN in UCSRB, send, unset TXEN or i can just set RXEN and TXEN so uC knows, that i will both read and write?
[11:19:59] <slidercrank> holy crap. I confused IN and OUT of a voltage regulator as its datasheet was somewhat confusing:
http://higgs.rghost.ru/42172496/image.png The whole frame is titled "top view" but below my model of the regulator (picture on the right) is the writing "bottom view" (contradicting with "top view" of the whole frame)
[11:42:44] <xata> slidercrank: as far as i saw this is a good tradition to show pins of one-sided packages on picture so that pins are turned to the observer
[12:07:34] <slidercrank> Xark, yes, I understand it now
[12:11:10] <Xark> slidercrank: I'm glad to hear that. :)
[13:03:11] <tld> http://www.outsidethebeltway.com/journalists_firearms_identification_guide/
[15:35:39] <jet> I'm having a problem with avr-gcc. If I compile this program my arduino can boot :
http://privatepaste.com/5ed6a28e79
[15:35:51] <jet> if I compile this program, my arduino doesn't boot :
http://privatepaste.com/bdba10ea0d
[15:36:35] <jet> the only difference is I create one or two global variable
[16:17:06] <yunta> jet: what's the first argument for HardwareSerial constructor?
[16:17:32] <jet> It's nothing
[16:17:59] <jet> I've taken the aruidno library, and I tried to reduce it until my arduino boots
[16:18:12] <yunta> HardwareSerial Serial2(0); <- what's that 0? what does that mean?
[16:18:36] <jet> that's zero
[16:18:50] <jet> I'm not using it
[16:19:05] <yunta> ah, shit
[16:19:09] <jet> but if I remove the parameter, there is no more bug, and my arduino boots
[16:19:18] <yunta> didn't notice you have the code higher :)
[16:20:26] <yunta> did you try this directly on avr, without arduino stuff ?
[16:21:12] <jet> I've reduce my example at 4 files in total (.c and .cpp files
[16:21:25] <yunta> also, where is definition of x ?
[16:21:47] <jet> http://privatepaste.com/d8660f0ff2
[16:22:14] <jet> this file is from the arduino library :
http://privatepaste.com/eb93d73aa5
[16:22:36] <jet> this file too :
http://privatepaste.com/1549171835
[16:22:50] <jet> for the .c and .cpp that's all
[16:23:04] <jet> for the header, that's a bit more complex...
[16:23:26] <jet> but the assembly that you saw contains all .elf file
[16:29:00] <yunta> strange..
[16:29:09] <jet> yes, I agree
[16:29:15] <yunta> looks like your working example doesn't call the stream constructor
[16:29:39] <jet> if I link the same object files on the mac, I don't have the problem
[16:29:46] <jet> the problem seems to be on the link phase
[16:30:10] <yunta> where did you link this one?
[16:30:39] <jet> with avr-gcc -Os -Wl,--gc-sections,--relax -mmcu=atmega2560 -lm -o blink_ardu/build/blink_ardu.elf blink_ardu/build/project/blink.cpp.o blink_ardu/build/project/HardwareSerial.cpp.o blink_ardu/build/core/core.a
[16:31:13] <yunta> same gcc version as on mac?
[16:31:20] <jet> no
[16:32:07] <jet> on freebsd :
http://privatepaste.com/21e959da83 on the mac :
http://privatepaste.com/a84443089d
[16:32:08] <yunta> so, the non-working gcc is which version? and on what distro?
[16:32:19] <yunta> asking out of curiosity, not that I can help....
[18:30:56] <MrTrick> I have a rather frustrating Heisenbug that I can't figure out. Adding a debug line stops the behaviour from occuring. Commenting it out brings the behaviour back.
https://gist.github.com/4250652
[18:32:08] <MrTrick> Anyone here like picking through assembler code? I'm wondering if the behaviour is somehow toolchain-related?
[18:32:24] <MrTrick> (I'd be perfectly happy for it to be user error, I just can't figure out what's going on)
[18:33:20] <Horologium> adding debug line where?
[18:33:39] <Horologium> and what is charlie_on, charlie_off?
[18:34:55] <MrTrick> So ISR A.c is the snippet with charlie_off/charlie_on commented out. ISR B.c is the snippet with them uncommented.
[18:35:39] <MrTrick> charlie_on is a simple lookup to light a particular LED in a charlieplex matrix. charlie_off switches the LED off.
[18:35:57] <MrTrick> in the assembly they get inlined, so you can see what it does.
[18:37:57] <Horologium> not up to digging through assembly tonight myself.
[18:38:00] <jadew> MrTrick, you didn't mention what the behaviour is
[18:38:17] <MrTrick> jadew: it's all in the gist.
[18:38:46] <jadew> where's minute_hand declared?
[18:38:49] <MrTrick> There are two versions of code, one of which is faulty, one of which behaves correctly.
[18:38:56] <MrTrick> At top-level.
[18:38:58] <jadew> is it volatile?
[18:39:20] <jadew> ah, it says there
[18:39:21] <MrTrick> yup, I just copied the declarations into the commentary
[18:42:28] <jadew> what's the debug line?
[18:44:34] <jadew> so charlie_off will turn everything off, charlie_on will turn stuff on in a specific pattern
[18:44:40] <jadew> what happens if you turn on only a single led?
[18:44:45] <jadew> or a pin, do you have a scope?
[18:45:06] <jadew> you can take a look and see if the ISR is actually getting executed the way you want, maybe the issue is somewhere else
[18:45:29] <jadew> also, using the same functions that might be part of the problem is not a good way to debug stuff
[18:45:37] <jadew> you should try to output something else
[18:46:27] <MrTrick> I was using the charlie functions for debugging.
[18:46:59] <MrTrick> Also, if I take all those out, and set a breakpoint in the overflow code, it also works correctly.
[18:47:09] <MrTrick> But if no breakpoint, then it fails.
[18:47:27] <jadew> just remove them and output something on a pin and see if you're getting what you are expecting in the first place
[18:47:39] <jadew> the fact that its working doesn't necesarily mean that everything is ok
[18:47:48] <jadew> it might work by mistake
[18:48:15] <MrTrick> uh, as in; with breakpoint, takes 10 seconds between increments. Without breakpoint, takes 5 seconds.
[18:48:54] <jadew> ok, so your problem is that its going faster?
[18:49:30] <jadew> altho, I must agree the breakpoint thing is kinda weird
[18:49:55] <jadew> maybe the linker screwes up in the optimisation step, but you can't assume that yet
[18:50:43] <jadew> I'd check the way you set up the timer
[18:50:59] <jadew> maybe you're using some uninitialized variable
[18:51:28] <jadew> when in debug mode, the linker might initialize that var to 0, however in optimized state, it might leave it as it is
[18:51:36] <jadew> do you get warnings when you compile that things?
[18:52:04] <MrTrick> timer is
https://gist.github.com/4250652#file-init-of-timer-c
[18:52:07] <jadew> (altho not sure it can figure out if you're using an unitialized var)
[18:52:49] <jadew> looks good I guess
[18:55:34] <MrTrick> hmm, there were some warnings, but nothing to do with this code.
[18:56:45] <jadew> btw, you should isolate the code
[18:56:55] <jadew> make sure nothing else is happening except that ISR
[18:57:09] <MrTrick> Yes, that's true.
[19:00:29] <MrTrick> I'll try some more things when I get the chance (at work now)
[20:09:07] <slidercrank> what does "should be left opened" mean (about a pin)? does it mean it should not be connected to anything?
[20:09:35] <jadew> yeah
[20:09:40] <slidercrank> thanks
[20:09:51] <jadew> np
[21:19:12] <MrTrick> ooh, while talking about pins... someone's design had all their unused I/O pins connected to ground, as they said 'for power saving reasons'.
[21:19:26] <MrTrick> Good idea? Or bunkum?
[21:20:43] <Tom_itx> not so good
[21:20:51] <Tom_itx> what if you accidentally drive one high?
[21:21:40] <Essobi> Anyone play with chip45's RS485 bootloader?
[21:22:26] <Essobi> Thinking about buying the source and making it multidrop aware.
[21:23:37] <Casper> MrTrick: never let a pin floating, it cause unnessessary switching, causing higher power usage... and possibly self destroy some IC that do not have protection....
[21:23:46] <Casper> so yes, it's true
[21:23:49] <Casper> but he do it wrong
[21:23:54] <Casper> just set the pin to output
[21:24:09] <Casper> or enable the internal pullup and keep it input
[21:30:35] <MrTrick> What do you mean? That pins should be left unconnected, but set as either output or input with WPU?
[21:31:54] <Tom_itx> yeah
[21:40:44] <MrTrick> right.
[21:43:38] <Tom_itx> i'd tend to set them as ouput then they won't be suseptible to stray noise as inputs
[21:47:22] <Essobi> *-/2
[23:33:09] <TeknoJuce> happy 12/12/12 #AVR
[23:45:18] <Casper> oh crap
[23:45:31] <Casper> I missed the 12/12/12 12:12:12.12
