Back
[03:52:21] <limpkin> hello everyone
[03:52:37] <limpkin> has anyone tried specifying the progreammer on avrdude using -P on linux
[04:20:09] <sabor> limpkin: -P is the (serial) port, for example: avrdude -c stk500 -P /dev/ttyUSB0 -p atmega168 -U flash:w:switch.srec
[04:21:06] <limpkin> yeah it doesn't enumerate that way
[04:21:16] <limpkin> but anyway i found a way to reprogram the serial number on a diamex all avr
[06:18:54] <Emil> limpkin: hm?
[06:18:58] <Emil> What serial number
[06:19:00] <Emil> Also
[06:19:31] <Emil> have you guys run into a problem where you print out a bunch of memory that's initialised with unsigned chars
[06:19:39] <Emil> and then you change offset, expecting the overflow to happen
[06:19:42] <Emil> but for some reason it doesn't
[06:19:55] <Emil> like
[06:20:42] <Emil> rxb[256], rxo=0; and then later in the code loop serial_putc(rxb[rxo]+i);
[06:20:59] <Emil> That should overlow, right?
[06:21:13] <Emil> sorry
[06:21:18] <Emil> rxb[rxo+i]
[06:21:21] <Emil> Like that
[06:21:39] <Emil> rxo+i should always be between 0 and 255
[06:21:50] <Emil> But for some reason I'm getting crab all of the that memory space
[06:21:56] <Emil> crap*
[06:22:36] <Emil> And only if I change the rxo (which is 0 by default)
[06:26:20] <Vikinger> why is this: DDRB |= _BV(PB2);
[06:26:20] <Vikinger> DDRB |= _BV(PB3);
[06:26:20] <Vikinger> DDRB &= ~_BV(PB0);
[06:26:25] <Vikinger> DDRB &= ~_BV(PB1);
[06:26:44] <Vikinger> diferent then this : DDRB = 0x03;
[06:26:49] <Vikinger> ?
[06:28:10] <aczid> it doesn't affect the other bits...
[06:28:36] <aczid> oh and uuh _BV(3) = 1<<3 so
[06:29:04] <Emil> First sets the second bit, seconds sets the third bit, third clears 0th bit and last clears 1st bit. DDRB=0x03 sets the two lowest bits
[06:29:08] <Emil> So they are different
[06:29:12] <aczid> the sum of the other statements is actually gonna make the lowest 3 bits '100'
[06:29:30] <aczid> in stead of 011
[06:30:35] <Emil> aczid: he asked how they are different
[06:30:37] <aczid> oh I missed the first statement
[06:30:52] <aczid> I'm trying to help explain how they are different?
[06:30:59] <aczid> maybe I should try again after a coffee ^^
[06:31:26] <aczid> your explanation is good
[06:36:13] <specing> Aaaaah cryptic C
[06:36:18] <specing> gotta love it
[06:38:06] <Emil> specing: cryptic C, where?
[06:40:05] <aczid> cryptic indentation :P
[06:41:36] <specing> Emil: everywhere
[06:44:44] <Vikinger> i know they dont work the same
[06:44:50] <Vikinger> but they should
[06:45:06] <aczid> 1100 is not 3
[06:45:22] <Vikinger> if i do DDRB = 0x03 i expect to have inside DDRB = 00000011
[06:45:24] <Emil> Vikinger: no, they shouldn't
[06:45:42] <Emil> Vikinger: yes, that is correct
[06:45:58] <Vikinger> but it doesn work
[06:46:01] <Emil> Vikinger: please review the bit operations
[06:46:05] <Emil> | sets bits
[06:46:07] <Vikinger> if i set bit by bit then works
[06:46:08] <Emil> & clears bits
[06:46:16] <aczid> 1100 != 0011
[06:46:44] <Emil> Vikinger: use the 0b notation if you want it to be waaaaayyyy more readable
[06:47:10] <aczid> that's a gnu extension though :)
[06:47:13] <Emil> so
[06:47:17] <Emil> gcc for lyfe
[06:47:18] <aczid> yeah very useful
[06:47:21] <Emil> and that's what atmel also uses
[06:47:36] <Emil> 0x03==0b00000011
[06:47:51] <aczid> fair enough, atmel also use IAR for example
[06:48:01] <aczid> I also prefer gcc
[06:48:05] <antto> avrgcc ftw
[06:48:29] <Emil> While those bit operans leaves you with 00001100
[06:48:49] <Emil> Vikinger: do you see your problem?
[07:06:13] <Vikinger> Emil: no
[07:06:19] <Vikinger> but i have to leave
[07:06:30] <Vikinger> and ill be back
[07:08:26] <Emil> A functional avr terminal
[07:08:33] <Emil> On one sitting
[07:08:36] <Emil> I should go sleep now
[08:43:01] <carabia> < specing> Aaaaah cryptic C <- I think the syntax for bitwise operations is pretty uniform across a great deal of languages. Now if you want to be a software nerd and only learn marginal stuff such as Ada, good luck getting hired
[08:44:17] <carabia> furthermore _BV is just a macro for a shift, don't use it if it's "cryptic". not an inherent fault of c
[08:47:07] <theBear> hmm, so if i disapprove of the wide range of new/young languages just on principal, and avoid things like pascal and haskell (yeah they rhyme, it's nice, but only coincidence :[ ) cos i deem it too obscure/little-used,does that make me a software super-cool-dude ?
[08:47:42] <theBear> or is that just another coincidence ? you know, that i do feel that way AND am a super-cool-dude
[08:48:37] * theBear has forgotten more programming-related things than most people know even exist :-)
[08:52:16] <carabia> theBear: i'm not sure if the question is relevant, as the syntax seems quite well established for quite a long time, why change it in the first place?
[08:57:43] <theBear> you mean my question ? that was more general, not about bitwise anything :) bitwise stuff always kinda seemed to correlate pretty directly to digital logic electronics/generic concepts in my mind, but my mind doesn't work like most
[08:58:06] <theBear> by correlate i spose i mean come-from
[09:01:34] <carabia> well, my comment was just based on someone calling the provided snippet cryptic. i wasn't talking in general
[09:02:35] <theBear> yeah i know :) if i ever question how cool i am you can assume it's not a real serious question, cos theBear don't need validation
[09:02:53] <antto> get xmega, then you can PORTB.SET = 0x03; and stuff like that
[09:02:57] <carabia> theBear: is, and always has been. amen
[09:04:35] <theBear> heh, you know th escore
[09:05:16] <carabia> antto: well you usually should write your code in a saner (is that a word?) fashion anyway
[09:06:07] <antto> but that isn't exactly comparable to the atmega
[09:06:50] <antto> if you PORTB |= 0x03; on the atmega - the current port value is read first, afaik
[09:07:29] <carabia> umm
[09:10:03] <crazy_imp> antto: not sure, the compiler might decide to use sbi $reg,0x1 and sbi $reg,0x2 instead of reading, or-ing, writing
[09:10:22] <crazy_imp> (sbi = set bit in i/o register)
[09:10:42] <antto> how about 0x7F then
[09:10:47] <carabia> that's actually an interesting question
[09:10:48] <antto> 7 instructions?
[09:11:17] <antto> in any case, you can do the same on the xmega too, but you can also .SET or .CLEAR
[09:11:21] <antto> and .TOGGLE
[09:11:26] <antto> nifty!
[09:12:07] <crazy_imp> antto: depends on the -O level? cycles vs instruction size
[09:13:23] <crazy_imp> would guess it'll do a read, or, write then
[10:17:03] <Tom_L> .
[11:06:28] <Jartza> wtf
[11:07:04] <Jartza> https://www.youtube.com/watch?v=kLnk6vnc7w0
[11:07:16] <Jartza> I had that ^ running on screen and then I left to grocery
[11:07:25] <Jartza> came back, the red and green bar are gone
[11:07:39] <Jartza> I thought, well, I just restart the chip
[11:07:51] <Jartza> I did. they don't come back.
[11:07:57] <Jartza> reflashed the chip. they don't come back
[11:08:09] <Jartza> only the curving thing in the middle
[11:08:51] <Jartza> checked the code. can't see anything wrong with it (and haven't touched that after I woke up today)
[11:09:27] <Jartza> the only thing I can think of: the code uses RAM only for those bars, cpu registers for rest
[11:09:34] <Jartza> could it be that SRAM has died
[11:17:40] <Lambda_Aurigae> are they supposed to be there?
[11:32:37] <Jartza> yes
[11:32:45] <Jartza> and the code looks good
[11:33:00] <Jartza> I noticed the cat has slept on breadboard :P
[11:42:14] <Jartza> nope
[11:42:18] <Jartza> doesn't show the bars anymore
[11:42:19] <Jartza> LOL
[12:00:31] <carabia> cook the cat, i hear they taste like chicken
[14:20:47] <joebobjoe> I'm kind of confused by this block diagram in the ATtiny85 datasheet
[14:20:49] <joebobjoe> https://www.dropbox.com/s/6b4vsv2xq5wio3m/Screenshot%202016-12-17%2014.17.45.png?raw=1
[14:21:14] <joebobjoe> In SPI the output is buffered by the gated D-latch
[14:21:48] <joebobjoe> In the diagram it has a low-enable, but doesn't that mean the latch is activated in the wrong part of the clock cycle?
[14:22:48] <joebobjoe> According to my reading of that diagram, on a rising edge the USIDR shift register will be clocked and the latch will become transparent
[14:23:34] <joebobjoe> But shouldn't the latch be transparent when the clock value is low
[15:08:03] <joebobjoe> oh
[15:08:13] <joebobjoe> Someone on #electronics said it doesn't mean low-enable
[15:08:20] <joebobjoe> That is probably means "latch-enable"
[15:08:23] <joebobjoe> ugh now I get it
[15:08:28] <joebobjoe> such a noob
[16:41:46] <Jartza> LOL
[16:41:52] <Jartza> it seems my attiny5 fried it's SRAM
[16:41:58] <Jartza> strangely, CPU registers still work
[16:42:08] <Jartza> I always thought they were actually part of same SRAM block
[16:42:34] <Jartza> no matter what I write there, it always returns 0
[16:44:19] <Tom_L> maybe the tools are broke
[16:44:27] <Tom_L> did it work before?
[16:44:33] <Jartza> yep
[16:44:57] <Jartza> https://www.youtube.com/watch?v=kLnk6vnc7w0
[16:45:11] <Jartza> it was displaying that (just looping the same thing) since yesterday
[16:45:24] <Jartza> I visited grocery, meanwhile the red and green bar had disappeared
[16:45:33] <Jartza> everything else is in CPU registers, except the vertical location of those bars
[16:45:35] <Tom_L> tryin to give me convultions?
[16:45:49] <Jartza> and the curvy thing in the middle of the screen is still showing :D
[16:45:59] <Jartza> I was like wtf, almost called an exorcist
[16:46:22] <Jartza> reflashed the chip multiple times, erased, reprogrammed fuses, high voltage programmed...
[16:46:27] <Tom_L> where's the B
[16:46:30] <Tom_L> in RGB
[16:46:35] <Jartza> in reset
[18:06:35] <sebus> Jartza ;o Maybe fake chip? I've encountered similar problems with m644, m128, tiny13 from aliexpress. They were way worse - ie random reset. Btw. Graphics reminds me of TIA chip :-)
[18:11:40] <Jartza> I hope it's authentic as it's sample from Atmel :D
[18:12:23] <Jartza> this didn't reset randomly. the cat went sleeping on top of my breadboard while I was doing croceryshopping
[18:12:38] <Jartza> I'm suspecting static, the cat is verry furry
[18:12:51] <Jartza> everything else works, except RAM just reads 0
[18:13:25] <Jartza> but for a short while it felt like calling ghostbusters because... those lines should not just disappear :D
[18:13:39] <Jartza> especially spooky when rest of the screen still works like it should
[18:14:23] <sebus> ouch, that hurts.. but wait... interrupt works ? (push/pop instructions)
[18:14:29] <sebus> so... wierd :D
[18:15:25] <Lambda_Aurigae> ram is static sensitive...and heat sensitive too.
[18:15:30] <Lambda_Aurigae> could have overheated.
[18:18:19] <sebus> More likely static charge would fry/damage pin driver inside or tvs protection, not SRAM... I think.
[18:35:49] <Jartza> sebus: I don't use push/pop
[18:36:15] <Jartza> like I said, most of the stuff is in registers, but the vertical location of those bars is in SRAM :)
[18:36:54] <Jartza> Lambda_Aurigae: I don't think it would've overheated
[18:38:52] <Jartza> few days ago I played around with thermal cam while the chip was running @12MHz
[18:38:56] <Jartza> so, max speed
[18:39:02] <Jartza> it barely gets hotter than room temp
[18:39:17] <Jartza> room is about 23°C, the chip was something like 26°C
[18:39:17] <Lambda_Aurigae> but kitty temp....
[18:39:29] <Jartza> well, kitty is about 39°C :)
[18:39:30] <Lambda_Aurigae> :}
[18:39:33] <Jartza> shouldn't be a problem
[18:40:01] <Jartza> and due the wires he couldn't have slept on top of the chip actually
[18:40:29] <Jartza> but he's been very... statically charged lately, as it's wintertime here and everything is super dry and electrified
[18:40:48] <Lambda_Aurigae> kitty cats as emp weapons!
[18:40:55] <Jartza> indeed
[18:41:09] <Jartza> he's a nuisance sometimes. he likes to sleep on my laptop keyboard or on my breadboards :D
[18:41:15] <Lambda_Aurigae> we can drop half a million cats on russia and win the war!
[18:41:16] <sebus> Jartza replace chip and let us know, if it fails again. And don't use HCF asm instruction :-)
https://en.wikipedia.org/wiki/Halt_and_Catch_Fire
[18:41:29] <Jartza> sebus: that was my only attiny5 :(
[18:41:40] <Jartza> gonna get more though, but I need more of those breakouts for sot23 too
[18:41:44] <Jartza> to use them on breadboard
[18:42:45] <sebus> Besides, my cat loves to play with TO-3 transistors. :D
[18:43:00] <Jartza> :)
[18:43:06] <Lambda_Aurigae> wife's cat likes to help her sew.
[18:43:20] <Lambda_Aurigae> cat's favorite is pins and needles....
[18:54:50] <carabia> Jartza: that temp sounds a bit off
[18:55:29] <carabia> ideally the cat temp should be around 80 deg c
[18:56:09] <carabia> well, a bit less than that.
[18:59:34] <Lambda_Aurigae> 80C?
[18:59:44] <Lambda_Aurigae> seems a bit warm to me
[19:03:52] <carabia> no i think it seems just about right
[19:04:32] <Lambda_Aurigae> 176degF?
[19:16:24] <Tom_L> 9° F outside
[19:17:36] <Lambda_Aurigae> 1.6F here
[19:17:46] <Lambda_Aurigae> carabia, you do realize that 80C is the temp of a well done steak?
[19:17:58] <Lambda_Aurigae> cat should be served medium at most.
[19:42:44] <abcminiuser> Hey Tom_L, what's your email these days?
[19:50:57] <abcminiuser> *poke*
[20:05:32] <Tom_L> same as it ever was
[20:05:46] <abcminiuser> Can't find it in my archives :S
[20:06:06] <abcminiuser> I have someone who think's I'm you, asking questions about your programmer HW
[20:06:14] <Tom_L> oh
[20:06:20] <Tom_L> i'm not peddling them now
[20:06:27] <Tom_L> but i have a couple left i think
[20:06:43] <Tom_L> atmel's does much more now for the same cost as the old dragon
[20:07:02] <Tom_L> they having problems?
[21:02:53] <carabia> Lambda_Aurigae: i take it, you have done this before?
[21:03:17] <Lambda_Aurigae> well, I've eaten cat before,,,but didn't know it till afterwards.
[21:03:26] <Lambda_Aurigae> dog too.
[21:04:13] <carabia> dog i can borderline understand though not a fan of that. Cats, i couldn't care less
[21:05:11] <carabia> i don't fry steaks nowhere near 80 degc, however, if i was to eat cat i would fry the living shit out of it for all the shit they can carry
[21:05:22] <FL4SHK> I like to add with carry
[21:05:38] <carabia> FL4SHK: sharp as ever
[21:08:02] <Lambda_Aurigae> I prefer subtract with carry myself.
[21:10:22] <Lambda_Aurigae> carabia, what's the last two things a cat should hear?
[21:10:29] <Lambda_Aurigae> "PULL!" *BANG*
[21:10:45] <FL4SHK> NOOO
[21:10:50] <FL4SHK> don't kill cats :(
[21:10:59] <Lambda_Aurigae> this was told to me by a baptist preacher
[21:11:03] <Lambda_Aurigae> in the church!
[21:12:50] <carabia> well, preacher gets props outta me
[21:13:01] <carabia> would be pretty fun to shoot cats in skeet
[21:13:19] <carabia> maybe they should change the ruleset for the olympics on trap/skeet
[21:14:11] <carabia> they could blow out some super fat cats like those norwegian forest cats or something
[21:17:02] <learath> carabia: use lawyers instead.
[21:19:13] <carabia> in skeet i think they shoot two discs at the same time so you could have one tube spitting cats and another lawyers. Perhaps a third one for liberals.
[22:06:19] <Eszett_> hi
[22:06:27] <Eszett_> have you asked here arij?
[22:07:03] <arij> I haven't
[22:09:02] <Eszett_> does someone know why the "content mismatch" error shows up, when trying to set fusebits of a Atmega32U2 with a USBASP device and AvrDude?
http://puu.sh/sTaXa/04ff6dee45.png
[22:09:30] <Eszett_> "avrdude: verification error; content mismatch"
[22:17:33] <Casper> communication error
[22:17:38] <Casper> or faulty chip
[22:17:52] <FL4SHK> or faulty error, or communication chip
[22:18:10] <Eszett_> hm
[22:18:37] <Eszett_> well ye its a error, but how can I solve it?
[22:29:13] <carabia> oh please usbasp
[22:29:40] <carabia> buy china, get china
[22:33:07] <Eszett_> reading the fuses is working, so I guess the chip cant be that faulty.
[22:37:40] <sabor> Eszett_: i had a similar problem a while ago, writing flash and eeprom worked fine, writing fuses too until i wanted to set the eeprom fuse bit, maybe there's a software problem somewhere...
[22:39:24] <Eszett_> I had the problem once too
[22:39:30] <Eszett_> Now im trying to help arij
[22:39:39] <Eszett_> But i dont remember anymore how i solved it
[22:39:47] <Eszett_> @sabor
[22:40:33] <Eszett_> I dont understand the logic behind the "content mismatch" error
[22:40:45] <Eszett_> what is Avrdude doing there and why?
[22:40:50] <sabor> i also don't know anymore how i solved it :(
[22:40:50] <abcminiuser> Sorry Tom_L had to duck out
[22:40:59] <abcminiuser> I've forwarded the email to you
[22:42:09] <abcminiuser> And yeah, the new Atmel ICE is actually decent for the price, it's no Dragon level of cheap, but at least it supports all the chips and is fast
[22:42:15] <abcminiuser> I got a shiny one recently:
https://twitter.com/abcminiuser/status/803178229779398656
