Back
[01:33:45] <iR0b0t1> Haha, I swapped SDA and SCL.
[01:33:52] <iR0b0t1> Two days... gone.
[01:34:29] <Casper> :D
[01:34:36] <Casper> picnic
[01:37:39] <lifeeth> ROFL
[01:47:26] <CapnKernel> I hate that.
[04:01:40] <specing> iR0b0t1: thats like the first thing I test when something doesen't work ;P
[04:01:55] <iR0b0t1> Well I mean
[04:02:09] <iR0b0t1> the first few times I switched them it didn't work, and some doc told me the wrong thing.
[04:02:37] <iR0b0t1> Also, question: If I am pulling a pin to ground and it does not reach ground (and hovers a little above it) does that mean I am overstressing the pins?
[04:24:43] <CapnKernel> iR0b0t1: How are you pulling it to ground?
[04:30:00] <iR0b0t1> CapnKernel: Pin sink
[08:29:29] <JyZyXEL> is there a better way of doing this:
http://pastebin.com/ugZbPRwS
[08:37:25] <specing> Yes
[08:37:35] <specing> stop using ints, it irritates me
[08:38:50] <theBear> heh
[08:39:30] <specing> JyZyXEL: because its storage capability is different on every single fucking compiler for every single architecture
[08:39:40] <specing> #include <stdint.h>
[08:39:47] <specing> and use uint8_t
[08:40:06] <specing> Also
[08:40:11] <JyZyXEL> why _t?
[08:40:21] <specing> "unsigned int" is 16 bit on AVRs
[08:40:24] <specing> AFAIK
[08:40:54] <specing> So you won't only be wasting space, but the interrupt routine will be about 5 cycles slower
[08:40:55] <JyZyXEL> only reason i didn't use uint8_t is because i couldn't remember how it was written at the time of coding
[08:41:09] <JyZyXEL> i knew it was something int8 but couldn't remember it was uint7_t
[08:41:13] <JyZyXEL> uint8_t*
[08:41:30] <specing> JyZyXEL: Make yourself a header where you typedef these to u8, s8, u16, s16, etc
[08:42:18] <JyZyXEL> what is the _t for anyways?
[08:42:27] <specing> see stdint.h
[08:42:47] <JyZyXEL> any other improvements?
[08:43:32] <specing> Yes
[08:44:01] <specing> 1) fix your uart comm so you don't get errors (I never got them even when I was doing bitbanging)
[08:44:41] <specing> 2) use packet based messaging (preamble, command, param, crc?)
[08:45:09] <specing> 3) Don't make so many comments
[08:46:13] <JyZyXEL> i mainly did it because: screen /dev/ttyUSB0 9600 sends some crap to it
[08:46:18] <specing> 4) put the first if into the else if
[08:46:39] <theBear> mmm, efficiency, normalisation, all that
[08:47:23] <specing> 5) Don't echo back stuff in the receive routing if you are also doing transmitting somewhere
[08:48:27] <JyZyXEL> thats the only transmitting im doing
[08:48:28] <specing> 6) the second condition in the 'else if' is completely redundant
[08:49:28] <specing> 7) insert a newline between ) and {
[08:49:54] <JyZyXEL> i don't agree with 7)
[08:49:57] <specing> ^ helps with readability for fucntions that have longer definitions
[08:52:01] <exDM69> matter of taste
[08:52:12] <JyZyXEL> whats the packet based messaging?
[08:56:50] <cehteh> some blind guy once told me he likes the { on the same column as the } as it makes programming with a braille terminal much easier
[08:57:05] <cehteh> point taken
[09:26:47] <JyZyXEL> cehteh: holy crap thats a good point
[11:02:23] <Landon> /win 1
[13:35:55] <ferdna> what do you think his location is?
[13:35:57] <ferdna> http://www.youtube.com/watch?feature=player_detailpage&v=iKl5BlH6MSM#t=291s
[13:37:25] <Tom_itx> sea level
[13:39:00] <ferdna> somewhere in uk
[13:39:11] <ferdna> just can get the lat/lon right...
[13:41:40] <Tom_itx> enter it in google earth
[13:44:01] <ferdna> Tom_itx, i can't read the digits from the video =/
[13:44:18] <ferdna> 6.0666, 52.00 (mark A)
[13:50:01] <Casper> what I read is 00006.8667 52.300909
[13:54:13] <Casper> the data from the readout and the progs dosen'T seems to match...
[13:54:48] <ferdna> Casper, i read 5122.2797
[13:54:55] <Casper> 0.068702E 51.222815N 81.8 alt.
[13:56:24] <ferdna> that one is more believable
[15:32:25] <rhumbot> hi again. im trying to make a simple hello world like program run on a attiny13:
http://pastebin.com/dMrh6SpY nothing happens ... :)
[15:35:37] <Casper> rhumbot: wrong coding
[15:35:55] <Casper> 0<<foo do absolutelly nothing
[15:35:59] <Casper> and is even optimised out
[15:37:43] <Casper> rhumbot: PORTB &= ~(1<<x); ← to clear bits
[15:37:56] <rhumbot> ok. but when leaving out the part in the loop the pins are set to high/low correctly ...
[15:39:34] <Casper> what your code actually do:
[15:39:36] <rhumbot> i changed that and PB0 stays as 1 now
[15:39:49] <Casper> set PB0-4 to output
[15:40:06] <Casper> set PB2-4 high
[15:40:23] <Casper> then the loop:
[15:40:47] <Casper> set ONLY PB0 high, the rest of PB1-7 low
[15:40:48] <Casper>
[15:41:07] <rhumbot> why does it set the rest to low?
[15:41:22] <drgreenthumb> FTFY ;)
http://pastebin.com/tWVEzMcJ
[15:41:23] <Casper> the apparent result: PB0 goes high
[15:41:25] <Casper> that'S it
[15:41:50] <Casper> rhumbot: you tell the avr to set the port B to the result of 1<<PB0
[15:41:54] <rhumbot> your right but i dont understand it :(
[15:42:49] <Casper> portb = 4 + 8 + 16;
[15:42:52] <Casper> portb = 1
[15:42:58] <Casper> that's what you are currently doing
[15:43:25] <Casper> wait
[15:43:35] <Casper> even worse..
[15:44:05] <Casper> the loop actually turn only pb0 high, then all low
[15:44:40] <Casper> man... my mind have issues with such bad coding :D
[15:44:42] <Casper> ok
[15:44:43] <drgreenthumb> yes that's why I changed it to |= and &= in my fixed up version ;)
[15:45:40] <drgreenthumb> unless you're driving data out of a whole 8 bit port, you almost never want to assign the full port. just twiddle individual bits.
[15:47:50] <rhumbot> i changed it now:
http://pastebin.com/7wGdpU9W
[15:48:45] <rhumbot> the result = PB0 low all the time :(
[15:49:50] <Casper> are you sure you're checking the right pin?
[15:50:16] <Casper> and PORTB |= foo
[15:50:26] <Casper> same for the DDR
[15:50:35] <Casper> |= is "and equal"
[15:50:39] <Casper> err
[15:50:41] <Casper> OR equal
[15:50:54] <Casper> basically, it do foo = foo | bar
[15:51:15] <Casper> and set all the bits that are high...
[15:51:45] <Casper> &= is AND equal, so foo = foo & bar, it will keep the bits that are 1 on both side
[15:51:50] <Casper> the ~ invert the bits
[15:52:15] <Casper> so 1<<1 = 00000001 ~00000001 = 11111110
[15:55:29] <Casper> now... how do I add wheels to this tv stand...
[15:57:27] <Steffanx> Say: Hocus Pocus
[15:59:46] <Casper> if it was that simple....
[15:59:50] <Casper> sadly it is not...
[16:01:00] <Casper> I'm not even sure that I can actually find a way to install some
[16:01:13] <Casper> it's some square tubing....
[16:05:14] <drgreenthumb> heh yeah that'd be my guess, LED or whatever is attached to wrong pin. actually the first version that rhumbot posted should have actually worked, if a bit slopily
[16:08:16] <drgreenthumb> if it originally went high and stayed high, my guess is the load is actually attached to PB2, PB3, or PB4, which was getting set high and then left alone
[16:08:57] <drgreenthumb> and now the new version stays low because only PB0 and DDRB[0] are being touched.
[16:29:22] <Casper> or led in wrong direction
[16:31:03] <drgreenthumb> or maybe he forgot a resistor and it burned out. I love electronics ;p
[16:32:21] <drgreenthumb> had one burn out recently, picked too small resistor. it lasted about a year of solid use though.
[16:35:52] <drgreenthumb> it was a pretty stupid LED actually I shouldn't have put it there. it was showing that an IR receiver was actually RX-ing data that it could understand. but it was too close and all that light actually interfered a bit with the operation :)
[16:36:56] <drgreenthumb> which in the end meant you had to hold down the remote control buttons longer. so heh, evil LED
[18:15:28] <cehteh> when i call eeprom_read_byte from an ISR avr-gcc generates a huge push/pop overhead, is there some way to tell gcc what registers are clobbered by eeprom_read_byte()?
[18:15:52] <cehteh> (i could also eleminate the eeprom_read_byte there and put it in sram)
[20:17:30] <Casper> cehteh: afaik, no
[20:30:49] <OndraSter> when global warming comes... linux's tux will die because of the heat! :D
[20:36:01] <Casper> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
[20:42:29] <OndraSter> gn
[20:42:31] <OndraSter> it is 0331
[20:42:32] <OndraSter> arrgh
[21:42:53] <iR0b0t1> Sorry, this is something that's not immediately apparent from the datasheet... If I run an attiny off of the internal PLL as the clock, can I still use the undivided-by-4 frequency for PWM?
[21:42:57] <iR0b0t1> (driving timer 1)
[21:49:47] <Casper> check the datasheet for the timer clock source