Back
[05:32:50] <LeoNerd> I think I've just found my next geekery tshirt:
http://teespring.com/555timer-grey3
[05:34:33] <martinus> Heh, one of Dave's designs.
[05:35:05] <martinus> I love his channel but it took a while - his accent took me a while to get past his accent.
[05:40:37] <LeoNerd> I don't know if it's Dave's but I have seen him wearing one
[05:40:54] <LeoNerd> Oh right, it is his
[05:46:37] <martinus> Wow, I really need to proofread my sentences!
[05:46:54] <martinus> multitasking: Doing many things poorly. :D
[10:57:27] <redspl> hi guys..
[10:58:27] <Strangework> Hello :)
[10:58:32] <bss36504> Hola amigo.
[10:58:42] <redspl> i got trouble with crystal ;(
[10:59:02] <redspl> when i add it without capacitors, nothing
[10:59:46] <redspl> when i add it with capacitors(6x10pF, 3x for one "side" of crystal), nothing too
[11:02:14] <bss36504> Thats too much capacitance. Add like 20pf to both sides.
[11:02:47] <redspl> 20pf does not work too
[11:02:57] <redspl> i need to set fuse bits??
[11:03:00] <bss36504> on both sides of the crystal?
[11:03:17] <bss36504> oh yeah, set the fuse bits to the max startup time for a crystal.
[11:03:51] <bss36504> Thats a good starting point at least. You can decrease the startup time after, if you feel comfortable. But 256 clocks of startup has never really bothered me.
[11:05:28] <bss36504> actually, if you can still talk to the chip with a programmer, and you feel as though (or can verify) that the crystal isnt working, then you *definitely* need to update your fuse settings.
[11:06:03] <bss36504> because if the crystal was selected as a clock and it wasnt oscillating, then you wouldnt be able to comminicate with the chip.
[11:14:04] <Hexum064> morning all
[11:16:09] <Strangework> Mornin, Hexum064!
[11:19:48] <Hexum064> :D
[11:24:28] <redspl> i do not understand setting fuse bits..
[11:24:52] <redspl> i need to set(as i know) SUT0 to 1, and CKSEL0 to 1
[11:29:00] <redspl> OK, i got it! :D
[11:32:54] <Hexum064> lol
[11:34:51] <redspl> heelp
[11:35:45] <redspl> i tried to disable crystal, but i somehow set fues bits and.. mine atmega does not boot
[11:36:08] <redspl> (usbasp cannot set sck period and device signature is invaild)
[11:37:20] <martinus> disable the internal crystal?
[11:37:48] <martinus> (and by crystal I mean resonator)
[11:38:49] <martinus> What's the device?
[11:38:53] <redspl> atmega8
[11:39:10] <redspl> i setted fuse bits to 0b11000110
[11:39:37] <redspl> then wanted to restore fuse bits to original
[11:39:43] <martinus> How are you programming it? AVRDUDE or something else?
[11:39:52] <redspl> avrdude over usbasp
[11:40:02] <redspl> (on rpi is this could help)
[11:40:40] <martinus> What's the syntax of the command you used to flash the chip?
[11:41:19] <redspl> sudo avrdude -p ATmega8 -c usbasp -P usb -e -U lfuse:w:0b11001110:m -B 4800
[11:41:25] <redspl> that was the first command
[11:41:39] <redspl> to set fuse bits to external crystal
[11:41:43] <redspl> and then..
[11:41:51] <redspl> sudo avrdude -F -V -c usbasp -p ATmega8 -P usb -U flash:w:$1.hex
[11:41:56] <redspl> $1=led
[11:42:08] <redspl> i have a script for everything
[11:47:02] <martinus> defaults for the ATMega8 appear to be 0xD9 0xE1 (high then low) which would switch to the internal oscillator. I usually use the following syntax (168 here as an example): avrdude -c USBasp -p atmega168 -U lfuse:w:0xff:m -U hfuse:w:0xdd:m -U efuse:w:0x00:m
[11:48:16] <martinus> Have you successfully flashed the uC prior to the problem?
[11:50:16] <Strangework> random thing, redspl: have you ever tried using the 'linuxgpio' avrdude programmer, which bitbangs your GPIO pins to program AVR uCs?
[11:51:48] <redspl> no, i didnt, but i know i can. I will try with that later
[11:52:15] <Strangework> It worked easily enough on my beaglebone black. It's a cute little thing
[11:53:19] <martinus> re: the invalid device signature - be sure to double check the part number. m8 is ATmega8, m8u2 is ATmega8U2.
[11:54:16] <redspl> http://wklej.org/id/1758604/?hl=
[11:54:36] <redspl> ATmega8 as device signature works too
[11:55:47] <martinus> What happens when you invoke this with sudo?
[11:56:29] <redspl> http://wklej.org/id/1758606/ THAT is that script
[11:56:40] <redspl> it has 2x sudo
[11:57:41] <redspl> BTW: it is not really build8_8.sh
[11:57:44] <redspl> it is build8.sh
[11:58:11] <redspl> (first 8 is from atmega8, second 8 is from crystal freq)
[12:03:23] <martinus> I can't see anything that would cause the problem in your script however the first response in this thread (whilst it's 328 related) may be of help:
http://www.avrfreaks.net/forum/does-device-signature-0x000000-mean-atmega-bad
[12:08:35] <martinus> Oh yeah, -F is considered bad practice and I've seen many people recommend that one never uses it (unless they know exactly what they're doing)
[12:09:37] <redspl> so what i can do now? generate signal from 555 timer/atmega8 #2?
[12:10:27] <martinus> That seems to be the suggestion.
[12:10:44] <LeoNerd> Clocking troubles?
[12:11:14] <martinus> Doesn't one have to specify the encoding of the hex file? I notice that you've specified "flash:w:$1.hex", shouldn't that have :i appended to it?
[12:12:24] <Strangework> avrdude should be able to determine the type without it, though I personally always add the type flag
[12:12:54] <martinus> Ah, good to know.
[12:15:37] <redspl> it worked until that change
[12:20:07] <redspl> martinus, what delay before clock "tick"
[12:20:59] <martinus> Are you referring to the uC startup delay?
[12:21:14] <redspl> no
[12:22:16] <redspl> to unbrick mine atmega8 i must generate signal with delays, right?
[12:22:33] <martinus> Oh, I see.
[12:22:54] <redspl> so what delay
[12:26:45] <antto> martinus you had to add the :i if you want to specify full filepath on windowz
[12:26:50] <martinus> From what I understand you need a square-wave input of whatever clock frequency you specified in the fuse bits on XTAL 1 (probably 1MHz)
[12:28:41] <martinus> antto: Cheers, I've been using it under linux as it was mentioned in a guide. I'm at the (slightly competent) paint by numbers level currently so I still have to learn the *whys* of these options. :)
[12:44:12] <redspl> still does not work!
[12:44:14] <redspl> afk
[12:44:28] <redspl> eem not not work
[12:44:36] <redspl> i could not program atmega8#2
[12:44:44] <redspl> i will check the connections
[12:44:46] <redspl> but now AFK
[13:16:36] <ambro718> Hi. I'm wondering where the AVR-specific features of the "size" tool come from. In the AVR Linux toolchain from Atmel, avr-size can run with --format=avr and with --mcu=something it will print usage percentages. But I don't see this feature in vanilla binutils-2.25.
[13:28:26] <Hexum064> kinda trying to figure out the context of your question.
[13:28:27] <Jartza> it comes from atmel gbu toolchain
[13:28:34] <Hexum064> aaah!
[13:28:41] <Hexum064> Glad Jartza knew
[13:28:42] <Jartza> gnu, even
[13:29:37] <Jartza> http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.5/
[13:30:50] <Jartza> it's modified fron gnu toolchain, from that link you can find the sources
[13:42:09] <ambro718> I see, thanks
[13:43:55] <Jartza> p
[13:43:58] <Jartza> np
[13:44:10] <Jartza> sorry typos, typing with phone
[13:44:21] <Jartza> and I'm in hotel in Riga :)
[13:44:33] <Jartza> small lag in the ssh
[13:48:47] <ambro718> I am getting a compiler crash :(
http://ideone.com/wovKkO
[13:49:57] <ambro718> it happens both with Atmel's binary toolchain and with a from-source build.(
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/misc/avr-gcc-with-avr-libc/default.nix )
[14:08:41] <Hexum064> jeez Jartza. You are addicted!
[14:09:28] <ambro718> which avr-libc will gcc-5.1.0 work with?
[14:34:46] <ambro718> gah, and 4.9.4 fails to compile my code with: error: unable to find a register to spill in class 'POINTER_REGS'
[15:16:09] <Jartza> ambro718: why you need to use unsupported versions?
[15:16:38] <Jartza> gcc 4.8.1 is the latest official, with avr-libc 1.8.0
[15:17:14] <redspl> still have bricked atmega8
[15:17:16] <redspl> ...
[15:17:50] <redspl> when i will install that clock(other atmega8) to crystal port 1, what next?
[15:20:41] <redspl> lemme explain it other way..
[15:21:06] <redspl> i have bricked atmega8 because i changed clock fuse bits
[15:21:25] <redspl> first i changed it to 0b11000110
[15:21:41] <redspl> but then wanned to use atmega normally without crystal
[15:21:55] <redspl> and changed it to 0b01000??0
[15:23:16] <Jartza> umm
[15:23:31] <Jartza> fuse calculator?
[15:23:39] <ambro718> Jartza: because the latest "stable" stuff crashes on my code
[15:24:07] <redspl> Jartza, i could not program mine bricked atmega
[15:24:17] <Jartza> http://avrcalc.pl
[15:24:31] <redspl> even polish page.. 0.0 :D
[15:24:51] <Jartza> that's a nice fuse falculator
[15:25:00] <Jartza> calculator, even
[15:25:51] <redspl> Jartza, but i could not program it(even fuses)...
[15:26:02] <redspl> but thx so much, i will use it in future
[15:26:03] <Jartza> ambro718: well, if it's official toolchain, then atmel might be able to help
[15:27:11] <Jartza> redspl: yea, I mean, those bits really don't tell much without datasheet
[15:27:35] <redspl> i doed it "Like a boss"
[15:27:41] <redspl> AND it worked!
[15:27:48] <redspl> ... for first set
[15:27:53] <martinus> I didn't even use the fuse calculator, I googled "fuse settings Atmega168 16MHz crystal" then checked that the answer matched a few others. :D
[15:28:31] <Jartza> redspl: sometimes it's enough to just try again
[15:29:03] <Jartza> if you burn fuses for external clock instead of crystal for example, you need to provide ext. clock
[15:38:11] <redspl> i provided!
[15:38:38] <redspl> nevermind, lets just put that atmega to the garbage
[15:41:09] <martinus> redspl what clock source did you provide?
[15:41:13] <Strangework> :(
[15:55:32] <ambro718> so gcc 5.2 was JUST released - minutes after I've packed up 5.1 for AVR!
[16:02:45] <Jartza> :)
[16:03:42] <Jartza> I've managed with 4.8.1 though I tried newer compilers too
[16:04:32] <Jartza> optimizations are a bit better but the avr-gcc I found (4.9.x) didn't support for example attiny841
[16:04:48] <Jartza> so it seems it was badly patched
[16:12:33] <kdehl> Is salicylic acid bad for electronics?
[16:14:56] <kdehl> Ah. No acid.
[17:53:55] <Kre10s> hi. I'm using #define TMR0_OFF() {TCCR0B &= ~((1<<CS02)|(1<<CS01)|(1<<CS00));} to turn timers off. How can I guarantee that the IO pin goes low as well?
[17:54:33] <Kre10s> running TMR0_OFF(); CLR(COMPARE_PIN); doesn't work reliably.
[18:05:30] <Lambda_Aurigae> set the pin to output and low.
[18:05:33] <Lambda_Aurigae> it's in the datasheet.
[18:05:44] <Lambda_Aurigae> no clue what that CLR() function thingie does or doesn't do.
[18:06:31] <Lambda_Aurigae> to set a pin to output you set the corresponding bit in the ddrx register to 1.
[18:06:48] <Lambda_Aurigae> then set the corresponding bit in the PORTx register to 0.
[18:07:02] <Lambda_Aurigae> that guarantees said pin is set to output and low.
[18:07:15] <Lambda_Aurigae> http://www.elecrom.com/2008/02/12/avr-tutorial-2-avr-input-output/
[18:22:12] <Kre10s> Lambda_Aurigae, lol. The problem was the -nostartfiles -nostdlib -nodefaultlibs linker flags
[18:23:32] <Kre10s> That'll give you strange error messages like undefined reference to `__udivmodqi4' when you try to mod stuff. And totally screw with all kinds of stuff.
[18:23:48] <Kre10s> I forgot I had it set from when I was doing some ASM.
[22:04:32] <q_bert> glad to see there's a channel about this stuff
[22:05:29] <q_bert> i'm not very good but i'm trying to be thorough from the start.. i have a simple program that sets a port to high and low with delays after each of 900ms and 100ms
[22:05:50] <q_bert> what i notice after i flash and run is that the delays are much longer than 900ms and 100ms
[22:06:15] <q_bert> i am defining F_CPU to be the clock frequency of my AVR which i checked in the datasheet
[22:06:34] <q_bert> (it's ATMega16A which runs at 16MHz, so i'm using #define F_CPU 16000000
[22:06:35] <q_bert> )
[22:06:41] <Hexum064_2> You have to make sure you actually have the right clock source selected
[22:07:43] <Hexum064_2> so, if you are setting F_CPU to 16000000 and you do _delay_ms(500); and it is delaying for more than 500ms, your clock source is not 16mhz
[22:11:58] <q_bert> Hexum064_2: i'm following this as i understand it
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html
[22:12:06] <q_bert> "The idea behind is that compile-time constant expressions will be eliminated by compiler optimization so floating-point expressions can be used to calculate the number of delay cycles needed based on the CPU frequency passed by the macro F_CPU."
[22:12:31] <q_bert> if i shouldnt use 16Mhz then im not sure what to set F_CPU to
[22:18:26] <q_bert> i see it's saying compiler optimizations must be enabled or the delay can be longer, any idea how to check that
[23:58:44] <Casper> q_bert: do you have a 16MHz crystal?
[23:59:33] <Casper> F_CPU do NOT define the speed, it tell the code at which speed the µC is running at