Back
[00:31:12] <TechIsCool> So what is everyones favorite smps chip?
[00:31:41] <Casper> lt3789 but never used it :D
[00:46:59] <nn7> OK, I am thoroughly confused by something that I'd like some help with.
[00:47:18] <nn7> I've spent two hours trying to understand what's going on and haven't made any significant progress.
[00:47:31] <nn7> I wanted you to know that I did work on this before coming in here and bugging you
[00:49:12] <nn7> The part of my code is here:
http://pastebin.com/EfA5n15v
[00:49:34] <nn7> when I execute it I get "reading eeprom" and then nothing before it goes to sleep
[00:49:51] <nn7> when I wake it up, I get a kanjii character, a new line, a space, and then the "a" character
[00:50:14] <nn7> I've played with various combinations and the general result is that my characters get confused when the chip goes to sleep.
[00:55:47] <Casper> nn7: your clock isn't stabilised yet when you do the char print after the sleep
[00:56:49] <nn7> actually, watching it on the scope, the pin remains high during sleep
[00:57:00] <nn7> putting in a delay before the sleep command fixed it
[00:57:11] <nn7> *sigh* I spent so long arguing with the code on that
[00:57:36] <TechIsCool> nn7: I know what you mean
[01:02:20] <nn7> ok, thanks for humoring me :)
[01:02:28] <nn7> I am giving up for tonight. Have a great night!
[01:02:38] <nn7> or morning, wherever the sun hits you
[01:44:53] <creep> i like tha nem of this avr library, oh and i'm also confused downloading these files one-by-one without distinguishable visited links :
http://sourceforge.net/projects/cdk4avr/files/cdk-avr-base-libconfuse/2.5-20060611/
[01:45:08] <creep> *name
[02:11:12] <creep> TechIsCool<< uc3842
[02:11:16] <creep> tl494
[02:11:18] <creep> win ?
[02:12:05] <Casper> tl494 is old
[02:12:21] <creep> what do you think they use in your PC power supply?
[02:12:37] <creep> KA7500, the cheapest crap chinese remake of tl494
[02:14:20] <theBear> that's finally starting to change, but the majority of atx psus in the wild still run them
[02:14:34] <creep> haha i tell you something new
[02:15:08] <creep> i disassembled some magic PC psu, it had a very little transformer, and it was driving the TL494 equivalent upto >300kHz
[02:15:31] <creep> out of specs to achieve reduction of transformer size
[02:15:55] <theBear> that aint slow
[02:18:31] <TechIsCool> the tl494 is the same as the MC34063 correct
[02:18:40] <theBear> kanji only has one i :)
[02:18:46] <theBear> err, don't think so, same kinda function tho
[02:18:57] <theBear> actually pretty sure it isn't
[02:19:31] <theBear> someone empty the water tray so i can turn the aircon on and have a nap
[02:19:33] <theBear> err, please
[02:20:25] <creep> theBear<< btw
http://en.wikipedia.org/wiki/Beer%E2%80%93Lambert_law
[02:20:48] <theBear> lambert the sheepish lion
[02:20:53] <theBear> i love that song
[02:20:59] <theBear> oh wait, my browser is broken
[02:21:10] <creep> light through a substance and the product of the absorption coefficient of the substance, α, and the distance the light travels through the material
[02:21:44] <theBear> oh, like lambertian pattern.. yeah, i know that
[02:22:05] <theBear> i was a lighting tech for several years until i got all crippled up
[02:22:09] <creep> so, materials absorb logarithmically more power vs thickness
[02:22:32] <theBear> yeah, err, so ?
[02:23:12] <creep> theBear<< anyhing, like a cookie, so anything more than a few cms will probably absorb all incident IR radiation
[02:23:29] <theBear> mmm, i don't argue that for a moment
[02:23:47] <w|zzy> http://www.youtube.com/course?list=ECD7F7ED1F3505D8D5 <-- Good for any beginner in the AVR world.
[02:24:03] <theBear> wow.... this channel has really grown over the last few years
[02:24:32] <w|zzy> Yea. Even if you only take into account active users
[02:24:57] <theBear> hehe, even then
[02:27:12] <w|zzy> Im not sure whether i count as an active member :P
[02:27:34] <theBear> you look familiar, that's more active than many :)
[02:27:49] <w|zzy> we've had a few conversations
[02:28:08] <theBear> even better... i used to remember that kind of thing, but these are troubled times
[02:28:16] <w|zzy> Middle age?
[02:29:16] <theBear> heh, old age 40 years early... stupid defective back
[02:30:23] <w|zzy> :(
[02:30:39] <theBear> saw my regular doc thismorning, submitted my cripple papers to the govt, he says my best chance at ever being comfortable/useful again is becoming somewhat of a yogi, completely defeating all stress and worry that could possibly pass thru my mind... at least it's something to aim for, better than just sitting around being crippled
[02:30:56] <theBear> i wonder if there's gurus in this country
[02:31:11] <w|zzy> Are you overweight?
[02:31:45] <theBear> not even close, specially since i can't afford food at the moment
[02:32:12] <theBear> spine was wrong shape in a bunch of places when i was born, big car crash about 4 years ago, too much hard work, now it's just useless
[02:36:18] <w|zzy> :(
[02:36:40] <w|zzy> Only reason i ask is a cousin of mine had massive back issues. Though he was 170kg. Told he would need operations and what not.
[02:36:49] <w|zzy> Lost 60kg and no issues.. Rocket science?
[02:37:04] <w|zzy> Its upsetting though that his first doctor didnt recommend losing weight as a viable option.
[02:37:21] <theBear> not exactly... it's like fat people with bad ankles... surely deep down they know the solution...
[02:41:20] <w|zzy> Yeah... Well my cousin did...
[02:41:32] <w|zzy> Sucks that you have had such a bad run.
[02:43:26] <theBear> yeah, even the lady at the cripple employment agency i used to go to looked sad when she saw my age today
[02:57:55] <w|zzy> :/
[03:57:19] <jadew> morning
[04:22:40] <Tom_itx> morning
[04:25:00] <creep> h
[05:10:00] <w|zzy> morning
[05:10:42] <OndraSter> moin
[06:37:42] <[z_z]> hi all
[06:38:25] <kdehl> Hi.
[06:46:01] <Malinuss> hey!!!
[06:50:27] <Horologium> mmmm...morning..
[06:50:29] <Horologium> salami and feta cheese omelette for breakfast.
[06:51:44] <Roklobsta_> open the windows
[06:52:03] <creep> hey Horologium
[06:52:26] <creep> wakeupmusic ?
[06:53:26] <creep> Flyleaf - i'm so sick, Fully Alive
http://www.youtube.com/watch?v=iWIADZKU9dw hackers used to listen stuff like this on films Scooter - Let Me Be Your Valentine (Official Video HQ) @ 298 BPM
http://www.youtube.com/watch?v=ByTuHDdZOX8
[06:54:24] <Horologium> I don't listen to music in the morning.
[06:55:02] <Horologium> only when I'm driving or doing woodwork.
[08:09:39] <kdehl> Does anyone in here have experiences with the PS/2 keboard protocol?
[08:10:01] <tzanger> a little, why?
[08:10:30] <kdehl> I can't understand what's wrong. I don't seem to get the correct scancodes.
[08:10:45] <kdehl> Would you like to just have a quick look at my interrupt routine that handles the reading?
[08:11:11] <tzanger> what are you seeing vs what you're expecting?
[08:13:05] <kdehl> I'm pressing the 'a' key and so I expect 1C, but I seem to get different values. Mostly 66, sometimes CC, 78 and EE.
[08:14:24] <kdehl> http://pastebin.com/uMKJekVR
[08:14:50] <Grievre> when does INT0_vect get called again?
[08:14:57] <kdehl> On falling edge.
[08:16:00] <Grievre> do you have a logic analyzer or a scope?
[08:16:09] <kdehl> No, unfortunately, I don't..
[08:16:20] <kdehl> This is my interrupt_init():
[08:16:38] <kdehl> DDRD &= ~(1 << PIND2 | 1 << PIND3); PORTD |= (1 << PIND2 | 1 << PIND3); EIMSK = 1 << INT0; EICRA = (1 << ISC01 | 0 << ISC00);
[08:17:26] <kdehl> So, first what I do is set INT0 and INT1 to input. Then pull them high, enable INT0, and tell INT0 to be generated on falling edge.
[08:17:31] <kdehl> Is that right thinking?
[08:17:56] <kdehl> I'm quite a newbie (if that wasn't obvious already!), so I might have totally misunderstood something.
[08:18:06] <Grievre> kdehl: What is connected to INT0 and what is connected to the other pin?
[08:18:12] <kdehl> Oh, and I do sei(); at the end, too.
[08:18:35] <kdehl> INT0 is connected to CLK on the keyboard and PIND3 is connected to DATA.
[08:19:06] <kdehl> An interrupt _is_ generated when you press a key, so I guess at least I got that right. Hopefully.
[08:21:17] <Grievre> you have pullup resistors?
[08:21:33] <kdehl> The send_character() and send_string() routines only send characters to a buffer, it doesn't actually output anything on the display. Not until another button is pressed, the buffer is copied to the display.
[08:21:38] <kdehl> No..
[08:21:49] <Grievre> Er, the data and clock lines on a PS2 keyboard are open-collector
[08:21:59] <kdehl> Um.
[08:22:00] <Grievre> they need to be pulled up. I dunno if that happens on the keyboard side but it can't hurt to do it yourself as well
[08:22:16] <Malinuss> kdehl, you wut? you can't make a pin high if you just made it input? You just enabled the internal pullup resistor...?
[08:23:03] <Malinuss> " first what I do is set INT0 and INT1 to input. Then pull them high," or do you mean "enable internal pullup resistor"?
[08:23:20] <kdehl> I just followed this example, and it doesn't mention anything about any pull-up resistors, so I'm quite clueless:
[08:23:23] <kdehl> http://avrprogrammers.com/example_avr_keyboard.php
[08:23:34] <kdehl> Malinuss: Yes, sorry, I meant the internal pullup resistors.
[08:23:42] <Malinuss> oh okay nvm. then
[08:23:51] <kdehl> Hehe.
[08:24:06] <Grievre> kdehl: not an easy problem to solve without a scope...
[08:24:26] <kdehl> Yeah, I guess.
[08:24:31] <kdehl> Oh well.
[08:24:34] <Grievre> hmm wait
[08:24:38] <kdehl> ...
[08:24:45] * kdehl waits and hopes
[08:25:24] <tzanger> what is your INT0 configured for?
[08:25:45] <tzanger> INT0 can be configured for low-level int, rising edge int, falling edge int or either edge int
[08:25:53] <kdehl> Falling edge.
[08:26:07] <kdehl> EICRA = (1 << ISC01 | 0 << ISC00);
[08:26:11] <kdehl> I hope. :)
[08:26:18] <Grievre> kdehl: Er, according to the datasheet that's falling edge
[08:26:22] <Grievre> er RISING edge
[08:26:26] <kdehl> ...
[08:26:30] <kdehl> Oops.
[08:26:31] <Grievre> falling edge would be just ISC01
[08:26:58] <kdehl> You mean I should do EICRA = (1 << ISC01);
[08:26:58] <kdehl> ?
[08:27:58] <Grievre> yeah try that
[08:28:20] <kdehl> Page 66 of the 1284P datasheet says ISC01 set, ISC00 cleared, claims to be falling edge...
[08:28:24] <kdehl> Okay, I try.
[08:29:00] <tzanger> when you plug the keyboard in, do you get code 0xaa?
[08:30:01] <kdehl> Good question.
[08:30:06] * kdehl checks
[08:30:17] <Grievre> kdehl: Oh I was looking at the data for the wrong part then
[08:30:46] <kdehl> Um, no. I get FFFF.
[08:30:51] <kdehl> Bad sign, huh?
[08:31:16] <kdehl> Then I get 66 on the first press, and after that just EE.
[08:32:24] <kdehl> Wait a sec...
[08:33:44] <tzanger> also you are printing in the ISR
[08:33:48] <tzanger> that's bad practise
[08:34:11] <tzanger> your ISR should be collecting bits and flagging when it's complete
[08:35:07] <kdehl> Yeah, but the printing routines only put characters into a buffer, they don't do any true output. It's not until I press another button (that is not connected to an INTx pin) that the buffer gets sent to the display.
[08:35:31] <tzanger> doesn't matter. the ISR shoudl be as minimal as possible, there is no reason not to collect that in the main loop
[08:35:43] <kdehl> Okay.
[08:35:46] <kdehl> Hm.
[08:35:52] <tzanger> also I would have a timer interrupt that is reset on every bit collected and if the timer fires, abort the effort and start over
[08:36:01] <tzanger> that is glitch protection and robustness
[08:36:25] <kdehl> Yeah.
[08:36:31] <kdehl> Sounds like a good idea.
[08:38:31] <Grievre> kdehl: What speed do you have your serial running at?
[08:38:56] <kdehl> I have no idea.
[08:39:12] <kdehl> I don't send any commands to the keyboard, if that's what you mean.
[08:39:14] <Grievre> kdehl: Er um... you know that the data line is inverted right?
[08:39:30] <kdehl> ...no.
[08:39:37] <kdehl> Or yes.
[08:39:37] <Grievre> at least I think I read that
[08:39:54] <kdehl> I do pull it high, and then see if it is ... cleared.
[08:40:00] <kdehl> No I don't. I check if it's set.
[08:40:04] <kdehl> Oops again.
[08:43:26] <Grievre> oh wait no it's not inverted
[08:43:31] <Grievre> or is it
[08:43:32] <kdehl> Oh.
[08:43:35] <kdehl> Hehe.
[08:43:36] <Grievre> I dunno, it'd be easy to tell if you had a scope!
[08:43:39] <kdehl> Yeah, I think it is.
[08:44:04] <kdehl> if ( PIND & 8 ) data |= 0x80; // Add a bit if it is a one.
[08:44:07] <kdehl> That's from the example.
[08:45:07] <kdehl> That generates TRUE if PIND3 is zero, right?
[08:46:17] <Grievre> kdehl: uh... what type do you have bitcount declared as?
[08:46:29] <Grievre> it looks to me like you have an assignment outside of a function, not a declaration
[08:46:29] <kdehl> Unsigned char.
[08:46:47] <kdehl> Yeah, the default value is set to 0x00.
[08:47:38] <Grievre> btw
[08:47:44] <kdehl> Sorry, I added the two top lines outside the function right before I pasted it. It's wrong it's supposed to be:
[08:47:47] <kdehl> unsigned char data = 0x00;
[08:47:49] <kdehl> unsigned char bitcount;
[08:48:04] <Grievre> kdehl: so this: data |= (0x01 << (bitcount - 1));
[08:48:07] <Grievre> is better done as:
[08:48:10] <Grievre> data |= 1;
[08:48:11] <Grievre> data <<= 1;
[08:48:21] <Grievre> er, eek!
[08:48:22] <Grievre> wrong order
[08:48:27] <Grievre> shift THEN or
[08:48:32] <kdehl> Right.
[08:48:40] * kdehl remakes
[08:49:53] <kdehl> No.
[08:49:55] <kdehl> That's wrong.
[08:50:07] <kdehl> I need to do
[08:50:23] <kdehl> data <<= bitcount - 1; // don't I?
[08:50:42] <Grievre> no
[08:51:02] <Grievre> Every time you get a bit, you shift data left by one, and then put the bit in the new LSB
[08:51:10] <Grievre> basically software emulation of a shift register
[08:51:12] <kdehl> Oh yes, my bad.
[08:51:54] <kdehl> But I can't do it that way, since I count from 0 to 11, and not the other way around (11 to 0).
[08:52:12] <kdehl> Or=?
[08:53:42] <kdehl> I could do
[08:54:14] <kdehl> data >>= 1; data |= 0x80;
[08:55:23] <OndraSter> tip: if you are having issues with your program, check the gcc's version on the test srever
[08:55:24] <OndraSter> server
[08:55:25] <OndraSter> gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
[08:55:26] <OndraSter> ...
[08:55:32] <OndraSter> obviously this does not know #pragma pack(1)
[08:55:38] <Grievre> kdehl: Um, PS/2 gives you data LSB first
[08:55:40] <Grievre> not MSB first
[08:55:51] <Grievre> kdehl: bit 0 is the LSB
[08:56:38] <Malinuss> http://hackaday.com/2013/03/10/another-salvo-in-the-pic-vs-avr-holy-war/
[08:57:07] <Malinuss> pretty bad comparison I think
[08:57:16] <rue_house> yea
[08:57:23] <rue_house> Mhz, not instructions/sec
[08:57:36] <theBear> pfft, it's hackaday, whaddya expect ?
[08:57:40] <rue_house> didn't mention the paged memory pics have
[08:57:43] <OndraSter> haha theBear
[08:57:52] <Malinuss> theBear, what's wrong with it ?
[08:58:20] <kdehl> Grievre: Right.
[08:58:28] <rue_house> I dropped PICS when they made the non-backwards-compatible 16F84A
[08:58:34] <rue_house> like WTF!?
[08:58:53] <rue_house> there was no hobby programmer out
[08:59:02] <rue_house> couldn't use the old programmer with new software
[08:59:27] <rue_house> and they had no free C compiler, and the asm could only be so big before you hit a page boundry....
[08:59:34] <rue_house> it was the last straw
[09:00:05] <Malinuss> rue_house, oh wow... how is it now?
[09:00:25] <rue_house> I started as a pic guy, and I said "screw it, not worth the free samples"
[09:00:40] <theBear> Malinuss, for a start it's only uninformed comments on random links, 2nd, it's uninformed and poorly researched and apparently the writer(s?) have very little knowledge of what they write about
[09:00:40] <rue_house> I dont know, I use avr now
[09:01:16] <theBear> and if yer colourblind it's very hard to read
[09:01:33] <rue_house> the fact that avrs can be programmed in C for free means more recyclable code
[09:03:08] <rue_house> theBear, yea, they mis on some articles, but they are providing a fine "tech news" service, which I think is great.
[09:03:33] <kdehl> Grievre: I don't get it. I handle the bits when bitcount counts from 1 to 8, and I get the LSB first. Don't I need to put the bit in from the left and shift it right on each step?
[09:03:34] <theBear> a fine tech news service wouldn't make me scoff and see 5 errors in even 1 paragraph articles
[09:04:07] <theBear> lsb is on the right, if you shift right bits disappear/underflow
[09:04:16] <rue_house> I'm sure atmel would be happy to put a /4 on the system clock so an avr would "run" at 80Mhz
[09:04:26] <Grievre> kdehl: Oh hey you're right
[09:04:31] <Grievre> I'm a dumbass
[09:04:33] <Malinuss> theBear, I don't really read the articles, I mostly just follow the links if I think it sounds interesting...
[09:04:33] <theBear> you can turn a 1 into a 2, but you can't turn a 1 into a -1, that's not how binary works
[09:04:40] <theBear> wait, he is ?
[09:04:41] <rue_house> kdehl, can I see the code?
[09:04:43] <Malinuss> theBear, and for that I think it's great
[09:04:45] <kdehl> Grievre: Hehe. No worries. :)
[09:04:50] <kdehl> rue_house:
http://pastebin.com/GXQchmnQ
[09:04:52] <Grievre> theBear: Yeah if the LSB comes first that means that the /last/ bit you get is the MSB
[09:04:58] <Grievre> and therefore should not have any shifting happening after it
[09:05:12] <Grievre> so it goes on the left
[09:05:23] <Malinuss> rue_house, also you can be pretty sure that the current isp programming will be supported many years to come?
[09:05:25] <theBear> Grievre, oh, balls, totally, so each bit is worth err, 256 and you shrink ity
[09:05:36] <Grievre> 128
[09:05:43] <kdehl> rue_house: I did it a little differently there. But I think the end result should be the same.
[09:05:43] <theBear> meh, i was close, i'm outta practice :)
[09:06:01] <theBear> damn, i really shouldn't forget that one
[09:06:06] <Grievre> kdehl: what part again?
[09:06:10] <rue_house> kdehl, here is a question for you, which operator has prescedence, > or &&
[09:06:18] <theBear> precedence <grin>
[09:06:32] <theBear> or should i say <&grin&> :)
[09:06:55] <rue_house> hey, if I'm writing a public article I'll run a speel check ;)
[09:07:08] <kdehl> rue_house: Uh-oh. Good question! I always use parantheses to be sure.
[09:07:15] <theBear> hehe, good luck finding a speel check application boody :)
[09:07:25] <theBear> and that was accent, not spelling
[09:08:07] <rue_house> Malinuss, dosn't matter, the free source programmers already do 3 protocols
[09:08:58] <rue_house> not to mention jtag programming
[09:09:10] <Malinuss> rue_house, true, but in theory they could change to some proprietary programming method?
[09:09:10] <rue_house> if i ever want to be insane
[09:09:20] <rue_house> they wouldn't tho, thats the point
[09:09:33] <theBear> Malinuss, avr isp is proprietry, and they're good, it works on EVERYTHING
[09:09:51] <rue_house> microchip is like apple, they change everything in non-backward compatible ways on a whim
[09:10:03] <Malinuss> theBear, it is? Isn't there like 20 pages in each datasheet on how it works (never read it though)
[09:10:08] <rue_house> and expect the market to bend over and buy all new developemnt hardware from them
[09:10:22] <theBear> Malinuss, does that make it not proprietry ? (honest question)
[09:11:02] <Malinuss> theBear, at this point I'm pretty sure I don't know what proprietry means... and I'm guessing I just meant "not open" or "secret"...?
[09:11:04] <rue_house> theBear, it is possable to dig up the document on ISP programming
[09:11:09] <theBear> they don't let anyone else use it...
[09:11:26] <theBear> Malinuss, heh, me too, but generally i thought it was more like custom/specific to a company
[09:11:39] <theBear> rue_house, do YOU know what proprietry means ? someone must <grin>
[09:12:29] <rue_house> kdehl, what if bitcount is 0?
[09:13:05] <kdehl> rue_house: Then all that happens is that it gets incremented by one.
[09:13:32] <rue_house> does it
[09:13:35] <kdehl> rue_house: No shifting occours.
[09:13:44] <kdehl> Doesn't it?
[09:13:59] <kdehl> if(++bitcount == 11){...}
[09:14:22] <tzanger> kdehl: I usually do something like this
[09:14:41] <rue_house> iirc, ++var or var++ occuring in an if, will sometimes not save the value back to the variable......
[09:14:51] <theBear> sometimes ? c'mon rue !
[09:14:52] <rue_house> hmm
[09:15:00] <jadew> if it's a bug
[09:15:06] <rue_house> I avoid what he did in that if
[09:15:17] <kdehl> Hm. Okay, will do.
[09:15:17] <jadew> that statement is perfectly fine
[09:15:27] <jadew> unless the compiler is broken
[09:15:34] <tzanger> if (pin == 1) { data |= 1; } if (--bitcount) { data <<= 1 } else { got_data = 1; }
[09:15:42] <tzanger> depends on which way you need to shift
[09:16:07] <jadew> what's the original problem?
[09:16:08] <tzanger> you also don't need to actually save the start, parity and stop bits
[09:16:17] <jadew> serial decoding?
[09:16:22] <tzanger> you just need to detect bad state and restart if so
[09:16:27] <tzanger> jadew: ps/2 decode
[09:16:37] <jadew> ah
[09:16:47] <theBear> a quick search of the usual dictionaries and stupid wikis strongly suggests that the avr protocol is proprietry, and EVEN if they don't limit it's usage by OTHER COMPANIES, retaining total ownership and intellectual rights makes it proprietry :)
[09:17:05] <kdehl> I don't save any bits but the data bits.
[09:17:07] <theBear> regardless of openness
[09:17:08] <rue_house> for( temp = 128; temp != 0; temp >>= 1) {
[09:17:08] <rue_house> if ( LS166GetBit()) bits |= temp;
[09:17:08] <rue_house> LS166ClockPulse();
[09:17:08] <rue_house> }
[09:17:18] <kdehl> tzanger: I'll try that one.
[09:17:27] <jadew> what avr protocol?
[09:17:32] <theBear> isp
[09:17:37] <jadew> ah
[09:17:47] <rue_house> why use a linear bitcould when you can have a mask for the bit your using
[09:17:58] <jadew> well, would you expect microchip to use the same protocol? :)
[09:17:59] <theBear> just a minor question, we all noticed we don't know exactly what proprietry means
[09:17:59] <tzanger> a linear ... bit cloud?
[09:18:08] <jadew> ah
[09:18:12] <theBear> jadew, heh, might get them a lot more customers <grin>
[09:18:18] <jadew> hehe
[09:18:59] <rue_house> Its implied that prop. means unreleased specs, but I think its more often something done custom to a company
[09:19:02] <tzanger> kdehl: ah see it's lsb first
[09:19:13] <tzanger> so you'd do data |= 0x80 and >>=1 instead, sorry, I got it backward
[09:19:15] <theBear> rue_house, that's what the dictionaries suggest
[09:19:23] <rue_house> why use a linear bit count when you can have a mask for the bit your using
[09:19:30] <kdehl> tzanger: Yes. Hehe.
[09:19:37] <tzanger> rue_house: six of one, ahlf dozen of another
[09:19:48] <tzanger> I prefer to or in the same value and shift rather than change the or value
[09:20:02] <theBear> if had a mask, i'd like it to be an anon mask, those are cheeky and precocious !
[09:20:15] <tzanger> it's just as easy to say bit = 0x01 and if (pin == 1) data |= bit; bit <<=1;
[09:20:51] <tzanger> kdehl: you are stripping off the start, stop and parity bits aren't you?
[09:21:06] <jadew> tzanger, there's something wrong with that if
[09:21:06] <tzanger> I see you counting to 12 but I don't see you stripping off start/parity/stop bits
[09:21:22] <theBear> hmm, these days i drink cheap wine like a fish that err, drinks a lot of cheap wine !
[09:21:22] <kdehl> tzanger: Yes, I just ignore them.
[09:21:26] <tzanger> jadew: it's pseudocode and I'm without coffee. :-)
[09:21:35] <jadew> ah, ok :)
[09:21:45] <jadew> speaking of coffee, gonna get a dr pepper
[09:21:58] <tzanger> that's a funny way to pronounce coffee
[09:22:06] <kdehl> if(bitcount > 0 && bitcount < 9) {...} // I only deal with data in this block
[09:22:07] <theBear> heh, foreigners
[09:23:41] <jadew> kdehl, you need to check the start and stop bits if there are any
[09:23:55] <kdehl> jadew: Why? Can't I just ignore them?
[09:24:00] <jadew> otherwise your code could start in the middle of a transmission and all your data will be garbage
[09:24:03] <kdehl> For simplicity's sake.
[09:24:05] <rue_house> kdehl,
http://pastebin.com/p5cYzxuU
[09:24:10] <theBear> you can 'ignore' them if you are sure they are them
[09:24:23] <rue_house> isn't that easier?
[09:24:50] <rue_house> for msb first start at 0x80 and shift right
[09:25:09] <kdehl> rue_house: Maybe, yes. I'll try it.
[09:25:34] <rue_house> be aware as I wrote it, the 9th bit triggers the output
[09:25:45] <rue_house> I'm running to work here so dont have time
[09:26:00] <theBear> lol, heed the warning of rue, woooohh iiii ooooohhhhhhhhhhh
[09:26:09] <theBear> that was ghost sounds btw
[09:26:15] <theBear> or wind maybe
[09:26:36] <kdehl> rue_house: Okay. Thanks a lot for the help.
[09:26:38] <jadew> more like having a hard time in the bathroom
[09:26:45] <kdehl> I'll look into it.
[09:27:02] <theBear> jadew, nah, you musta read it with an accent <grin>
[09:27:36] <rue_house> else should re-if bitcount
[09:27:39] <jadew> is ps/2 serial?
[09:27:48] <jadew> I mean, is it the same protocol?
[09:28:00] <theBear> clocked serial, and i think you mean rs232 protocol :)
[09:28:08] <rue_house> ps2 is, synchronous serial
[09:28:17] <jadew> got it
[09:28:20] <jadew> didn't know that
[09:28:25] <rue_house> master always clocks
[09:28:31] <rue_house> bi-dir data pin
[09:28:34] <jadew> sounds really easy to sniff
[09:28:59] <theBear> totally, and surely you've seen little 8pin avr 'joke' projects like random key insert/modifiers
[09:29:02] <rue_house> theres a million source postings on internet for speaking it
[09:29:03] <theBear> or random mouse movers
[09:29:19] <rue_house> haha viruses went hardware
[09:29:30] <theBear> rue_house, for speaking ghost noises in irc ? awesome !
[09:29:37] <jadew> it's only a matter until they start replicating
[09:29:52] <jadew> *matter of time
[09:29:55] <theBear> fwoo, thank GOD ps2 is on the way out
[09:29:57] <rue_house> ok I'm 6 mins late...
[09:30:01] <theBear> we really dodged a bullet there
[09:31:42] <jadew> all the ports seem to be on the way out
[09:32:35] <theBear> meh, i only just got my 1st usb keyboard, and i still got two good ps2's built like tanks, possibly both from the late 80s, if ps2 existed then.... after the apocalypse, i'll be THE MAN !
[09:33:12] <tzanger> well you'llbe able to use the ps/2 keyboards as efficient blunt-force weapons
[09:33:19] <theBear> only use this cos the fingerprint reader makes me feel like i'm living in a hi tech future world
[09:33:22] <tzanger> I've got a model M around somewhere
[09:33:22] <theBear> heh
[09:33:47] <jadew> theBear, what keyboard is that with a fingerprint reader?
[09:34:01] <theBear> umm, it's a lenovo according to the label
[09:34:02] <jadew> tzanger, I have an M too, nicely stored
[09:34:21] <kdehl> I wen looking to buy a PS/2 keyboard and mouse yesterday. People kept thinking I was asking for something for Playstation 2. Bah.
[09:34:28] <kdehl> *went
[09:34:32] <theBear> lsusb says ibm corp. for the keyboard and sgs thompson fingerprint blah for the reader
[09:34:51] <jadew> theBear, is it one of those that look like a laptop keyboard?
[09:34:54] <theBear> kdehl, heh, it's like pc133 ram, harder and harder to find ANYWHERE
[09:35:03] <jadew> with a trackpad and trackpoint?
[09:35:07] <OndraSter> theBear, send me money on paypal and I will send you a BIG hand of them
[09:35:22] <theBear> jadew, nah, fullsize, 3/4 size wrist wrest builtin with no flange, little spanner in a breifcase multimedia button top right next to the lights
[09:35:43] <jadew> don't know those ones
[09:35:53] <theBear> OndraSter, i'm on the way out, i used to have boxes, plus if i had money i'd spend it on liquor, then cigarettes, then food
[09:36:09] <theBear> should take a pic, i built a new monitor stand a couple days ago i'm quite fond of
[09:36:23] <OndraSter> heh
[09:37:52] <theBear> it's based around an old sign, i think it came from a chemist or doctor surgery
[09:38:06] <kdehl> theBear: I know! What's up with the world nowadays?!
[09:38:18] <OndraSter> I have got... 3x32MB, 2x64MB, 4x128MB, 1x512MB and then two without any capacity writtenon them
[09:38:29] <kdehl> You know how hard it is to find 5.25" floppies for a Commodore 64? Man...
[09:38:36] <theBear> oh those, i got a whole bunch of them, i thought you meant keyboards :)
[09:38:41] <OndraSter> I have got original DOS 5.0 floppies, kdehl :D
[09:38:44] <jadew> me too :)
[09:38:47] <rue_house> I got 2 new boxes of 5.25"
[09:38:50] <theBear> i've got original win 3.11a for workgroups
[09:39:00] <OndraSter> I have got two win 3.11 sets of disks :D
[09:39:04] <theBear> not sure what happened to my last few versions of dos
[09:39:22] <jadew> I have doom 1
[09:39:27] <jadew> on disks!
[09:39:28] <theBear> and all my 1.9x and 2.11 and 4 were err, borrowed :)
[09:39:37] <theBear> my doom 1 and 1.4 were err, borrowed too
[09:39:40] <OndraSter> lol
[09:39:48] <kdehl> I have lots of boxes of 5.25" floppes. What I don't have is 8" ones...
[09:40:00] <OndraSter> I don't have 8" either
[09:40:08] <rue_house> hmm no 8"
[09:40:12] <theBear> i aint got 8" floppies, but i DO have a 8" floppy err, whaddya call those things kids never seen ? diskbox ?
[09:40:14] <OndraSter> I have got whole drawer full of 30 and 72 pin SIMMs though
[09:40:32] <rue_house> me too who wants simms!
[09:40:37] <theBear> yeah, i got a bunch of 30 pin, but only ONE pair of 8mb ones for 1/2 sbawe32 cards
[09:40:37] <jadew> I'm sure that if I'd look, I'd still find some games on tape, for Z80
[09:40:46] <theBear> rue_house, ooh, i'll take 2*8mb
[09:41:10] <theBear> one of these days if i can work it out with a reasonably sized avr i'm gonna turn one of the cards into a hw sampler/soundfont player
[09:41:19] <OndraSter> :D
[09:41:22] <OndraSter> theBear, get xmega
[09:41:25] <OndraSter> supports SDRAM upto 16MB
[09:41:27] <OndraSter> natively
[09:41:31] <theBear> looked into it medium level, pretty sure i can do is at those kinda speeds and fake the high byte
[09:41:47] <theBear> yeah, but it doesn't have an emu8000 synth/sampler chip on it
[09:41:54] <OndraSter> neither does regular mega
[09:42:04] <theBear> the reasonably sized chip is to drive an awe32 isa card
[09:42:15] <theBear> now we both not confused, cos i was for a minute there
[09:42:15] <OndraSter> you still need some RAM :P
[09:42:22] <theBear> lol
[09:42:45] <OndraSter> I have got some 4, 8, 16 and maybe even 32MB 72pin SIMMs
[09:42:47] <theBear> the emu8000 chip accesses local ram itself, i just gotta load samples into it and then trigger it, maybe tweak some filter/effect settings
[09:42:53] <OndraSter> and 8x4MB 30pin ones at least
[09:42:57] <OndraSter> working in 486 board :P
[09:43:08] <theBear> i've got lots of 72pin, even a set of big edos for a server
[09:43:16] <theBear> i can thank young rif for those
[09:43:24] <theBear> i suspect rue delivered them, but it was a long time ago
[09:44:42] <OndraSter> rue = your colleague?
[09:44:44] <OndraSter> co-worker?
[09:45:28] <theBear> nah, just some robot builder from canadia.... many years ago, shortly after the start of the robotics channel, he visited rif just a few hours north of me, and they both visited me a couple times, it was an honor, and i learned much
[09:45:28] <OndraSter> LOL they stuck 0603? 0402? cap below the J-leaded DRAM chip
[09:45:40] <OndraSter> ah
[09:45:59] <theBear> i suspect it's still the biggest ever #robotics get together :)
[09:47:15] <theBear> lol "oh, i don't believe in hypothetical situations"
[09:49:17] <OndraSter> during an exam, theBear ? :D
[09:49:21] <OndraSter> (reply to the teacher)
[09:49:57] <theBear> heh, not too far off.... i'm watching a show on my other monitor floating atop my glorious new stand
[09:52:27] <jadew> what show?
[09:52:39] <theBear> it is called 30 rock
[09:52:55] <jadew> heard about it, probably from you
[09:53:48] <theBear> unlikely, unless it was a similar question... used to be on LATE here, got the good baldwin, some lady i forget the name of, and some other dudes i don't know the names of, well done, just slightly less than mainstream humour
[09:54:06] <theBear> too intelligent to be REALLY popular :)
[09:54:13] <creep> OndraSter<< ofc
[09:54:16] <creep> no problems
[09:54:41] <creep> decoupling worksbest UNDER the SMD
[09:54:43] <creep> ^^
[09:54:53] <jadew> gonna check it out
[09:55:02] <Malinuss> theBear, there is a robotics channel? what is its name?
[09:55:10] <Tom_itx> #robotics
[09:55:10] <theBear> lol, one guess buddy :)
[09:55:15] <Tom_itx> #seattlerobotics
[09:55:24] <Tom_itx> silly boy
[09:55:40] <theBear> seattle ? really ? is it as awesome as ours, or is that some kind of in joke i don't get after this much wine ?
[09:55:55] <Tom_itx> it used to be the largest in the US
[09:56:25] <theBear> but, that's sposed to be texas !
[09:56:28] <Tom_itx> not online but their group
[09:56:35] <Tom_itx> no that would be DPRG
[09:57:06] <theBear> but ! everything is bigger in texas ! have i been lied to ?
[09:57:19] <tzanger> creep: there used to be RAM devices that actually had a hollow under them for thin ceramic capacitors
[09:57:32] <theBear> tzanger, i always wondered what that was !
[09:57:59] <tzanger> it's fallen out of fashion now with BGAs and 0201 and 01005 parts but still it was a neat trick
[09:58:04] <tzanger> kind of like POP packages from TI
[09:58:10] <Tom_itx> if they were gonna bother with that why not just imbed them in the silicon
[09:58:22] <creep> ground plane is fine too...
[09:58:30] <creep> but doing vias is not much fun
[09:58:32] <theBear> they hadn't invented embedding back then
[09:58:34] <tzanger> Tom_itx: because it's hard to put a cap in an IC, they take a lot of space and require different processes
[09:58:44] <theBear> i mean the word :)
[09:59:24] <tzanger> they do put tiny caps in ICs but anything over a hundred pf or so (I think that number's right out of my ass) they put them external
[09:59:53] <creep> maybe the go up to 10nf
[10:00:56] <tzanger> remember that dram uses capacitors, billions of them
[10:01:57] <creep> as a gate of fets
[10:02:32] <creep> 1pf?
[10:42:16] * kdehl declares mission failed
[10:42:17] <kdehl> :(
[10:45:22] <tzanger> kdehl: what does your code look like now?
[10:46:28] <kdehl> Oh man. I started testing stuff I didn't know what it did, so it's all messed up. :)
[10:46:37] <kdehl> I just copied it from some example code.
[10:46:51] <kdehl> But I can get back to where I know what I do...
[10:51:48] <kdehl> tzanger:
http://pastebin.com/CUzrapjh
[10:51:54] <kdehl> That's what I have. The complete main.c
[10:53:17] <kdehl> The send_string() and send_character() routines only put the arguments into a buffer, and only when I call update() (which is done in the main loop if the external button is pressed) the text buffer is sent to the LCD.
[10:54:12] <tzanger> kdehl: learn to use git. you don't need a server. make small changes, commit them with meaningful messages
[10:54:16] <tzanger> you can *always* roll back then
[10:55:03] <tzanger> you should be using the standard AVR macros for port access instead of reinventing the wheel (and potentially causing insidious little bugs)
[10:55:45] <tzanger> that can't me your entire source, you reference update() but it's not in that file
[10:56:02] <kdehl> Right. Hold.
[10:56:11] <kdehl> Absolutely, I should start using git.
[10:56:28] <tzanger> it's saved my ass more times than I'd like to say
[10:56:37] <tzanger> I even put my hardware designs into git now
[10:56:56] <kdehl> That's smart.
[10:57:04] <kdehl> http://pastebin.com/BcDzVbeA <=- display.h
[10:57:25] <theBear> interesting .. long ago i considered it for a moment.... but over the years i have noticed even the simplest programming/hw projects get out of hand very quickly
[10:57:36] <theBear> as far as revision control and versioning and stuff
[10:57:39] <kdehl> http://pastebin.com/wtESMfep <=- display.c
[10:59:20] <kdehl> tzanger: You mean I shouldn't do 'BUTTON_PIN |= 1 << BUTTON;' for instance?
[10:59:47] <yunta> + for git. I wouldn't get anywhere without it. I'm also using it for hw designs.
[11:00:17] <theBear> some would argue that BUTTON naming is a useful level of abstraction
[11:00:33] <Tom_itx> LCD_CONTROL_DIR |= 1 << LCD_ENABLE | 1 << LCD_RW | 1 << LCD_RS;
[11:00:46] <Tom_itx> LCD_CONTROL_DIR |= 1 << LCD_ENABLE | 1 << LCD_RW | 1 << LCD_RS;
[11:00:49] <Tom_itx> woops
[11:00:59] <Tom_itx> what's wrong with that?
[11:01:10] <yunta> it's doubled
[11:01:17] <theBear> ;p;
[11:01:20] <theBear> lol
[11:01:50] <kdehl> I don't get it.
[11:02:15] <kdehl> That is the display init, which seems to work, though.
[11:04:59] <kdehl> Note that when I press the button, I set bitcount to 11 again...
[11:05:47] <kdehl> In case I'm in the midst of a reading, and I got out of sync somehow, pressing the button restarts the reading loop.
[11:11:35] <kdehl> I think that somewhere I have fundamentally misunderstood something...
[11:36:49] <hetii> Hi ;)
[11:40:24] <hetii> I need connect some rfid reader to tablet. Is it possible possible by avr emulate storage, that will be handled by OTG ?Then the idea is to store as a file the scaned code, and then process id by android applucation.
[11:44:14] <Casper> some AVR have USB OTG function, and standard usb, that might work if you can write the code. good luck
[11:44:38] <Casper> usb = hell
[11:51:59] <[w_w]> Casper, +1
[11:52:44] <Casper> http://imgur.com/a/qf4sR ← that is +10!
[11:53:14] <[w_w]> hetii, are you designing an rfid reader?
[11:54:17] <Casper> actually hetii is designing a paypass reader
[11:54:24] <kdehl> Nah, I guess I need an oscilloscope to figure this one out... Damn.
[11:54:27] <Casper> long range one
[11:56:22] <[w_w]> I would just use the usb cdc code from atmel. and hack an android app to use it.
[12:15:39] <kdehl> Can the keyboard know whether I have read a scancode already?
[12:16:29] <kdehl> That doesn't seem likely to me, I have to obey the CLK pulse via an interrupt, so I guess it assumes that I read it when it does start ticking, right?
[12:23:57] <d12_> I have a code to handle 8 bit SPI msg
http://pastebin.com/Yeq6j5Rr but how can I read a 16bit spi message since SPDR is a 8 bit register?
[12:26:36] <[w_w]> kdehl what kind of keyborad? the keyboard i think of when you say keyboard is a usb device.
[12:27:55] <kdehl> [w_w]: Oh. Heh, no I'm talkinga bout PS/2.
[12:28:19] <[w_w]> read the app note on ps2 yet?
[12:28:37] <[w_w]> atmels got a nice application note on how to handle ps2
[12:29:35] <[w_w]> www.atmel.com/Images/doc1235.pdf
[12:30:23] <kdehl> Yeah, I saw that one. I still couldn't figure out what is wrong with my software though...
[12:31:00] <kdehl> The only think I can think of is that I could be out of sync somehow, but I dunno. I do reset the counter in a way that I think should work...
[12:31:55] <kdehl> I do get different scan codes for different keys, I get several codes if I keep a key pressed longer and then release it. But the codes I do get are alll wrong.
[12:33:36] <[w_w]> are they at least all the same?
[12:34:06] <[w_w]> like pressing k produces 42 consistantly, or is the code allays different/erradic
[12:34:26] <kdehl> I do get the same scan code each time the same key is pressed, yes.
[12:34:38] <kdehl> Or whatever code it is that I get. Heh.
[12:35:58] <[w_w]> what do you get when you press a?
[12:36:28] <kdehl> 66
[12:36:41] <kdehl> And I get 64 fo Q and 67 for Z.
[12:36:44] <kdehl> All hex.
[12:37:04] <kdehl> I should get 15, 1c, and 1a, respectivly.
[12:37:16] <kdehl> Hm. Maybe they're all shifted.
[12:37:22] <[w_w]> yes. regardless of shift...
[12:39:27] <kdehl> Hm. No, I see no logic here...
[12:40:39] <[w_w]> code here says 0x1c == a... are you re-syncing if more than 1.5ms goes by?
[12:41:04] <kdehl> I manually resync after each time I press a key on the keyboard.
[12:41:15] <[w_w]> "If 11 bits are not received within
[12:41:16] <kdehl> I didn't know that rule, though.
[12:41:16] <[w_w]> 1.5 ms, some error have occurred. The bit counter should be reset and the faulty data
[12:41:16] <[w_w]> discarded."
[12:41:39] <kdehl> Ah.
[12:42:01] <kdehl> I guess I didn't read that document very thoroughly...
[12:43:13] <kdehl> But anyway, like I said, I do reset the counter manually when I update the LCD.
[12:43:24] <[w_w]> :P why not forget your project for a day and reproduce the project described in the app-note exactly the way it is there. then modify/integrate it to suit you needs.
[12:44:18] <kdehl> Yeah, actually.
[12:44:32] <kdehl> Maybe I should.
[12:45:40] <Malinuss> d12_, did you figure it out?
[12:56:22] <d12_> I know SPDR needs to be copied when it receives the first 8 bit, but how can I do it? I guess ISR function will be called when the data is received, so that SPDR will hold the only the last 8 bit of the 16 bit data
[13:02:01] <Malinuss> d12_, which uC are you using?
[13:02:32] <d12_> Malinuss, it is a 168a
[13:02:49] <Malinuss> d12_, also what is sending the message? is it actually sending it as 16 consequential bits with no stop bits etc.?
[13:04:39] <d12_> Malinuss, an embedded board sends the message, l am not sure how it sends the message, let me check if I can find out something
[13:05:43] <tzanger> kdehl:
http://pastebin.com/z33hdChH
[13:05:50] <tzanger> try making your interrupt handlers and main loop more like that
[13:06:45] <Malinuss> d12_, if it actually sends it in some not-standard SPI way, you might need to write "software SPI"
[13:07:04] <kdehl> tzanger: Wow! You are amazing! I'll try in just a bit.
[13:07:06] <Malinuss> but it propably just sends the 16 bits, sending 8 bits at a time,
[13:07:22] <kdehl> _YES_!!!
[13:07:37] <kdehl> It works!
[13:07:40] <kdehl> ...I think.
[13:07:43] <kdehl> ...wait.
[13:09:30] <kdehl> Yes, it motherfucking does!
[13:09:55] <kdehl> tzanger: I managed to fix it the second after you pated that code.
[13:10:08] <kdehl> tzanger: I'll look in a bit to see if I did it similarly.
[13:11:18] <d12_> Malinuss, yes it sends 8 bits at time.. then does it mean that when the board sends a 16bit message, the ISR (SPI_STC_vect) function on my AVR will be called twice?
[13:13:24] <kdehl> tzanger: Excellent, you give an example on how to use the timer, that was exactly what I was going to investigate next.
[13:14:20] <kdehl> tzanger: Otherwise I did just what you did, let the interrupt routine flag to the main loop that there is data to be processed.
[13:14:24] <kdehl> tzanger: Thank you a million!
[13:15:46] <kdehl> All I'm doing right now is of course just dumping the raw scan codes, but I'll get into processing soon.
[13:15:52] <kdehl> Then: mouse input!
[13:21:54] <tzanger> kdehl: I forgot to get rid of start/stop/parity, you need to shift and mask, and optionally check start/stop and calculate parity
[13:23:53] <kdehl> tzanger: Did that already.
[13:24:37] <tzanger> I always try to make it work in the most braindead simplest way possible. then when it works I commit the code and start to figur eout how to do it smarter
[13:25:52] <kdehl> Yeah. That's a smart strategy.
[13:25:56] <Essobi> I tend to not opttimize before I have identified the bottlenecks. :D
[13:26:10] <Essobi> Nor spell to well on Mondays.
[13:26:14] <Essobi> *too
[13:26:15] <Essobi> ffs
[13:31:25] <tzanger> heh
[13:43:46] <Malinuss> d12_, yes. then you just need to do this the first time you get the 8 bit (in the interrupt) data = SPDR; and then the next time data = (data << 8) | SPDR; ... since you are in the interrupt, remember to make the "data" of a volatile int type
[13:44:47] <Malinuss> d12_, hope it's pretty clear
[13:48:10] <d12_> Malinuss, thank you. it is pretty clear
[13:50:32] <Malinuss> d12_, otherwise read this nice little tutorial on bit math:
http://playground.arduino.cc/Code/BitMath ... and one more time: remember to use volatile
[13:51:03] <TopHatHacker> can i contract someone on here to write some code for me :)
[13:51:06] <Malinuss> d12_, and change the volatile uint8_t data; to volatile uint16_t data;
[13:51:44] <Malinuss> d12_, otherwise it will just overfloat ofc.
[13:53:04] <d12_> thanks
[13:56:40] <Malinuss> np.
[14:23:00] <kdehl> Well, well. I guess the next logical step is the PS/2 mouse now, huh?
[14:25:23] <kdehl> I guess I should get myself a graphical display for that, though...
[14:29:11] <Malinuss> kdehl, just buy dirty-cheap 3$ nokia display, hehe
[14:39:52] <gkwhc> Hi! i know there are techniques for measuring battery capacity by using the RC time constant and threshold voltage of a pin , but cant seem to find any sources..would anyone happen to know of a good reference that provide explanations of how it works?
[14:48:35] <TopHatHacker> +1 on the nokia display.. easy as pie plus tons of examples for any uC
[14:49:26] <yunta> haha, nokia, lol
[14:49:59] <OndraSter> indestructible!
[14:50:05] <TopHatHacker> if you google nokia display with msp430 my example might be the one that pops up haha
[14:50:18] <TopHatHacker> oh shit, my covers blown.. I'm not an AVR junkie!
[14:50:44] <OndraSter> :o
[14:50:46] <OndraSter> o:
[14:50:54] <OndraSter> GET OUT OF THIS ROOM!
[14:50:56] <OndraSter> NOW
[14:51:00] <OndraSter> lol
[14:51:13] <yunta> room?
[14:51:19] <OndraSter> yes
[14:51:30] <GuShH> AOL alert
[14:51:52] <TopHatHacker> heh
[14:51:58] <TopHatHacker> thanks for the warm welcome guys
[14:52:01] <Malinuss> gkwhc, I have code for that, if you want
[14:52:23] <Malinuss> gkwhc, it might need some adjustment in the MUX setting, which depends on your uC
[14:52:56] <yunta> TopHatHacker: I'm not against using nokia parts. Their HW is cool.
[14:53:56] <TopHatHacker> ya and most of their interface LCD chips are easy to use
[14:56:22] <yunta> that reminds me I should revive one of my n900 displays....
[14:57:37] <yunta> I wonder how much time would it take me to actually make use of it with xmega
[15:03:18] <yunta> OndraSter: your usb stack, does it work on usb3 ports ?
[15:04:23] <OndraSter> haven't tried
[15:04:25] <OndraSter> but why shouldn't it?
[15:04:27] <Malinuss> yunta, if there is no information on the controller - months, if there are - hours ;D
[15:04:30] <OndraSter> I am more scared about usb1.1 ports
[15:11:10] <GuShH> yunta: 3.0 is backwards compatible as is sata
[15:13:36] <GuShH> I wonder what would happen if yunta met a eSATA USB connector
[15:13:42] <GuShH> his brain would explode.
[15:25:59] <yunta> GuShH: that's only relevant if you consider perfect usb2.0 device and completely strict hosts
[15:26:34] <yunta> unfortunately my dev doesn't work on at least some usb3.0 ports. works on all 2.0 ports I found so far.
[15:32:44] <TopHatHacker> someone said this over in the 43oh room but you guys might like them too
http://tinyurl.com/b2etuc5 some break out boards for surface mount components for free! only pay $18 shipping.. and wait up to 25 days for them to arrive :)
[15:33:06] <OndraSter> they are for few cents on ebay
[15:33:08] <OndraSter> cheaper than shipping
[15:33:12] <GuShH> It doesn't work on USK (Universal Serial Kludge)
[15:33:33] <GuShH> TopHatHacker: that's not free
[15:33:50] <GuShH> It's marketing. You are paying for them in the shipping.
[15:33:58] <TopHatHacker> meh, for $18 you can get 70 breakout boards... not a bad price. especially if you find other things to buy there
[15:34:22] <GuShH> Boy, it costs them nothing.
[15:34:33] <GuShH> When they panelize and space is left over, this is what they populate them with.
[15:34:50] <TopHatHacker> sorry.. won't post links anymore :P
[15:35:09] <GuShH> Post whatever you want, whenever. Except for pr0n
[15:35:30] <GuShH> I highly doubt you'll use 1 out of the 70 you bought
[15:35:49] <TopHatHacker> i didn't buy any yet :p waiting until i find something else on that site i want
[15:35:57] <TopHatHacker> then why the hell not
[15:36:21] <GuShH> Do they sell dignity? Oh no, there's an Arduino category.
[15:36:36] <GuShH> should've called the site notsparkfun.com
[15:44:27] <xata> hello
[15:45:11] <TopHatHacker> hello xata
[16:09:31] <hetii> re :)
[16:10:46] <hetii> Sorry i was off, what about my idea to connect rfid reader (use rs232) through some AVR to tablet with OTG??
[16:12:05] <TopHatHacker> hetii i'd quicker use a bluetooth to serial modlue connected directly to an rfid reader that outputs serial
[16:12:16] <xata> hetii: ft232r?
[16:12:22] <TopHatHacker> something like the parallax rfid reader and the rn-41 bluetooth adataper
[16:12:54] <hetii> bluetooth is not the solution for my case
[16:13:58] <TopHatHacker> ok, just a suggestion :)
[16:14:15] <hetii> well the ft232r is just bridge between serial and USB but i`m not sure if it could be supported on tablets where we have just OTG
[16:14:24] <TopHatHacker> the ioio board is a cool solution for USB.. and it doesn't require that a phone have OTG (not all phones have it)
[16:14:33] <xata> hetii: no it is not.
[16:14:51] <xata> it is much more advanced, even bitbanging
[16:14:52] <hetii> you mean ?
[16:15:36] <TopHatHacker> cool board
https://www.sparkfun.com/products/11343 worth a look
[16:16:02] <hetii> well. the point is to be able handle this reader from my application without some hack into android kernel if its possible.
[16:16:29] <TopHatHacker> (ioio board has an SDK :-P )
[16:16:51] <xata> it converts from usb to uart, and backwards. rs232 has +/-15 logic levels, so you need com-max232-ft232r-usb
[16:17:30] <xata> also be ready to write your kernel driver for your device
[16:17:41] <hetii> xata: my reader is in ttl level.
[16:18:53] <hetii> so for what you wrote i can use also v-usb + avr, but still it will required to write drivers on android devices
[16:22:00] <xata> hetii: emulating usb device on low-level (and cheap) avr's is a huge pain in ass, been there, had that. if your device is 0/5V logic levels you can use just ft232r. on the other hand some anal penetration can be refreshing for newbies.
[16:23:05] * xata still has that refreshing fever each time touching avr
[16:23:26] <Roklobsta> do you feel the same about PIC?
[16:24:16] <hetii> sure i know about the issues that can happens with AVR and v-usb stack but it was just idea and you are right i could use ft232r chip but still it will required from me to touch android and this is something that i want to avoid.
[16:24:42] <xata> Roklobsta: no, never liked it. more than 1 cycle for instruction is not the thing for uC's on such low MHz
[16:24:54] <Roklobsta> like 8051
[16:25:13] <xata> 6510 <3
[16:26:03] <tzanger> heh I feel the opposite, I dislike the PICs not for the hardware but the software
[16:26:08] <tzanger> mplab and proprietary bullshit compilers
[16:27:37] <xata> tzanger: well, that's not a trouble for me (HURRRR!)
[16:27:58] * xata fixes his eye patch
[16:28:09] <tzanger> xata: it's not about cost
[16:28:27] <tzanger> it's about a nonstandard, proprietary compiler and proprietary debug tools
[16:28:27] <hetii> http://www.ftdichip.com/Products/ICs/FT311D.html
[16:29:33] <xata> tzanger: oh.
http://zamolxismd.org/m/stallman.helion.pl/graphics/free_0801.gif
[16:29:47] <tzanger> haha I'm not an RMS or ESR fan
[16:30:07] <tzanger> I just like standard tools
[16:30:44] <xata> tzanger: gcc, and POSIX?
[16:31:05] <tzanger> I wrote a three phase soft starter for a PIC16F84/87/877 (each time I ran out of room they came out with the bigger version) -- that sold probably close to 100k units over its design lifetime
[16:31:09] <tzanger> that was all written in pic assembly
[16:31:16] <tzanger> I probably still have the code somewhere
[16:31:25] <tzanger> xata: gcc and gdb, yes
[16:32:45] <tzanger> CCS is a terribly joke, and xc is better, but proprietary and still have to deal with mplab/mplabx to debug
[16:33:01] <tzanger> er terrible joke
[16:33:30] <tzanger> the parts work perfectly fine, and have a good price and excellent support
[16:35:23] <kdehl> Malinuss: I've seen those. Have you tried them?
[16:35:29] <xata> tzanger: i got your idea. well, that's not about me, but i am a hobbist.
[16:35:52] <kdehl> I saw RMS once. It was about as messed up a speech as you would expect.
[16:35:59] <kdehl> Can't say I don't like what he does though.
[16:37:05] <asteve> I'd like to find a proof for (a-b)/(a-b) = 1
[16:38:08] <kdehl> Um.
[16:39:45] <Malinuss> kdehl, which?
[16:39:56] <Malinuss> kdehl, the nokia displays?
[16:40:06] <kdehl> Malinuss: Yeah. Sorry, I'm slow.
[16:40:08] <xata> just in theory. there is some IC from mid-80s, halted production ~20 years ago and there is hi-resolution scan of its circuit. how much will cost production of 1k devices?
[16:40:14] <tzanger> xata: it's six of one and a half dozen of the other; in the end it comes down to personal preference. I am curious what your reasons are, or if it's just arbitrary
[16:41:06] <tzanger> xata: depends entirely on the device; 1980s IC tech is ancient by today's capabilities, but 1k devices would make for an expensive per-unit
[16:41:12] <Malinuss> kdehl, yeah
http://www.youtube.com/watch?v=TPuxeqBrus4 I made a 3d renderer on my uC that would display .obj files from a SD card (wireframe view) and rotate/scale them etc.
[16:41:22] <Malinuss> on that display
[16:41:26] <kdehl> Malinuss: Cool! *checks*
[16:42:15] <Malinuss> the video was taken before the 3d renderer was finsihed though hehe
[16:42:15] <kdehl> Yeah, that was not 3D. Heh.
[16:42:18] <kdehl> But cool nevertheless.
[16:42:34] <creep> h
[16:42:42] <kdehl> But there are cheap color displays too, I've seen.
[16:42:43] <xata> tzanger: mos 6581 :3
[16:43:13] <tzanger> what's the SID got to do with PIC/AVR?
[16:43:14] <Malinuss> kdehl, yeah for like 15$ you can buy a 320x240 16bit color touch display lol
[16:43:26] <tzanger> oh
[16:43:27] <tzanger> duh
[16:43:32] <tzanger> sorry yes I see what you're saying now
[16:43:47] <tzanger> IIRC the 6581 had some oddities about its fab
[16:44:04] <tzanger> making 1k of them might be worthwhile as it's already a niche chip with a high price tag
[16:44:22] <xata> but yes, there is still some in second-hand stock, and fpga can emulate it. but they are sold already for $25 per unit
[16:48:58] <xata> tzanger: yes, 6581 has oddities, and its value is composed from oddities. so if some guy creates 1k units of rare 6581ar4 and sell them for 30$, that will be 30k$. while i heard that making that much ic's will cost ~100k. the question is - is that true?
[16:53:05] <tzanger> I believe that it will cost more than that. Like I said MOS processes aren't done anymore, so the foundries command high prices
[16:53:26] <tzanger> and even if you do get a foundry to make them, how "accurate" will it be compared to the original
[16:58:50] <creep> accurate PT100 platinum RTD/Callendar Van Dusen equation
http://pastebin.com/4BvB6VB4
[16:58:51] <creep> :)
[17:10:33] <RikusW> hetii: I don't think vusb even supports OTG
[17:10:43] <OndraSter> it does not
[17:15:36] <hetii> This FT311D looks promising but as we can read here
http://dangerousprototypes.com/2012/11/01/ft311d-errata-the-ic-doesnt-work-with-android-v4-1-and-above/ it will not work in latest android.
[17:16:55] <hetii> But in other hand it appears that revision C of FT311D has been fixed to work for Android OS 4.1
[17:37:52] <tzanger> creep: still on the quest for the perfect crust?
[17:40:10] <creep> tzanger<< coded this like 1.5 years ago, but thought you might be interested
[18:06:18] <kdehl> I hate not comprehending what's going on.
[18:06:57] <kdehl> My code stops working when I turn off optimizations. I get warnings that delays might not work, but I don't use delays in any critical way...
[18:10:27] <Tom_itx> anyone remember where arduino hides it's hex files?
[18:16:41] <Horologium> on the computer.
[18:16:47] <creep> H2O freezes at 0.01C :(
[18:18:59] <Tom_itx> moron
[18:20:54] * Horologium resembles that remark.
[18:21:10] <Roklobsta> under the couch cushions
[18:24:53] <Tom_itx> i figured it out
[18:40:54] <kdehl> So. I have some code:
[18:40:56] <kdehl> http://pastebin.com/uT9tdywq
[18:41:10] <kdehl> That handles an interrupt.
[18:41:28] <kdehl> Declared in ISR(INT0_vect) {...}
[18:42:07] <kdehl> But if I make a new function called handle_keyboard_interrupt(), and put all the code there, and call it from ISR(), it doesn't work.
[18:43:11] <kdehl> I assume this has something to do with the first question in the winavr FAQ, where they talk about volatile global variables, which I use in the interrupt.
[18:43:20] <creep> http://images.nonexiste.net/popular/wp-content/uploads/2013/03/There-s-no-app-for-that.gif
[18:43:22] <creep> haha
[18:43:24] <kdehl> But I use volatile on all the variables I have, and it still doesn't work.
[18:43:32] <kdehl> Any ideas? I'm clueless.
[18:48:03] <Malinuss> kdehl, normally interrupts should just change a single flag, or add to a counter, no execute more code, especially if they are fired often. I would sugest you to try that, even though that might not be the issue
[18:52:37] <kdehl> Malinuss: I know it's supposed to be kept as simple as possible, but I'm afraid it has to do a little more stuff in this case. I'm receiving serial data on that interrupt...
[19:03:06] <[w_w]> kdehl, what part of the code you posted is not working. or rather how do you know it doesn't work? looks to me like it should work find.
[19:03:49] <rue_house> theBear, why use simms, you can use static sram and not have refresh overhead
[19:04:08] <rue_house> kdehl, hey
[19:04:12] <rue_house> still awake?
[19:04:55] <Horologium> but,,,,simms are so sexy!
[19:04:57] <kdehl> Still here. :)
[19:05:58] <kdehl> [w_w]: I seem to get wrong data from the keyboard when I in ISR() call another function containing the exact same code as ISR() had before.
[19:06:22] <kdehl> Naturally, I'm not getting the wrong data, it's just the interpretation that gets wrong somewhere.
[19:06:44] <Horologium> generally you aren't really supposed to call external routines from ISRs,,or that's how I understand it...causes problems somehow or so I was told.
[19:07:16] <kdehl> Seems so, indeed.
[19:07:41] <[w_w]> sounds like the overhead is causing you to sample at the wrong time. how close to the baud-rate are you operating your chip?
[19:08:44] <kdehl> That I wish I knew.
[19:09:10] <Horologium> what is your processor speed? are you using internal RC oscillator or external crystal or external oscillator?
[19:09:26] <kdehl> I heard (from someone in here) that the controller runs at 1 MHz as default. I don't have an external oscillator.
[19:09:35] <[w_w]> you should be find calling functions from within an ISR. as long as you have enough stack space. and don't make the ISR naked.
[19:09:39] <Horologium> internal RC oscillator can sometimes be a problem with USART comms.
[19:09:53] <Horologium> as it is not real precise and can vary with voltage and temperature.
[19:10:30] <kdehl> I have: #define F_CPU 1000000UL // Which seems to be correct, because the _delay_ms() function works just as it should.
[19:10:35] <kdehl> So I guess it's 1 MHz.
[19:10:58] <[w_w]> and whats your usart baud?
[19:11:03] <Horologium> I know I've had to vary the baud rate settings by one or three up and down sometimes to make USART work reliably on the internal RC oscillator.
[19:12:04] <kdehl> I do not know.
[19:12:25] <kdehl> Is that something I need to configure on the controller?
[19:12:32] <Horologium> yeah.
[19:12:36] <kdehl> Ah.
[19:12:42] <kdehl> Well then.
[19:12:52] <Horologium> if you don't set the baud rate, how is it to know how fast to talk to the other end?
[19:13:17] <kdehl> I thought the clock on the keyboard just generated an interrupt as it needed...
[19:13:31] <Horologium> oh...so you aren't using the USART?
[19:13:48] <Horologium> that's something entirely different,,,listening to a ps/2 keyboard.
[19:14:12] <Horologium> I thought you were reading the keyboard and sending data out over the USART....my mistake.
[19:14:17] <kdehl> Oh. Heh. I read about UART (I believe) in the PS/2 docs, so I figured it was relevant. :)
[19:14:44] <[w_w]> got a scope to look at the signal you are trying to capture?
[19:15:05] <kdehl> Unfortunately, I don't have that.
[19:16:01] <kdehl> But I really doubt there's anything wrong with the signal though. Everything works perfectly, if I leave the ISR as it is. It's only when I put the code in a different function and try to call it that it gets messed up.
[19:16:12] <Horologium> clocked data stream I do believe....usual way is to use an external interrupt to read each pulse in the stream.
[19:16:27] <Horologium> that almost sounds like a lack of stack.
[19:16:33] <Horologium> this on that attiny13a?
[19:17:49] <kdehl> It's a 1284p... that should have sufficient memory, shouldn't it?
[19:19:22] <kdehl> And I don't really call that many functions in the code to begin with...
[19:19:27] <Horologium> should.
[19:20:09] <kdehl> Hm.
[19:21:42] <[w_w]> i could imagine that the signal is somehow ringing, or the pulses just short enough to work with no overhead, and not with some overhead.
[19:22:31] <kdehl> I could test it, by calling a dummy function instead that doesn't do anything with the data.
[19:23:03] <Horologium> The clock frequency is 10-16.7 kHz. The time from the rising edge of a clock pulse to a Data transition must be at least 5 microseconds. The time from a data transition to the falling edge of a clock pulse must be at least 5 microseconds and no greater than 25 microseconds.
[19:23:15] <Horologium> that is,,,in theory...from a page on the ps/2 protocol.
[19:23:24] <[w_w]> or you could increase the clock speed of your proc.
[19:23:40] <Horologium> yeah...turn off the divide by 8 prescaler and run it at 8MHz
[19:23:42] <kdehl> That I could do. Can I just do that with avrdude?
[19:24:27] <[w_w]> you should also update #define F_CPU ...
[19:24:39] <kdehl> Ah, right.
[19:25:02] <[w_w]> just to be correct even if your not using delay_ms code.
[19:25:20] <Horologium> two ways to do it...one is to turn it off in the fuse..the other is to change it at runtime.
[19:26:06] <[w_w]> ah yes. with respect to the prescaler, the fuses just govern startup.
[19:26:26] <kdehl> Ah, okay.
[19:26:30] <Horologium> yup.
[19:26:47] <kdehl> I'm trying to figure out how to do it here... just a sec...
[19:26:52] <Horologium> I've used the prescaler changes at runtime in the past.
[19:29:23] <Horologium> change the CKDIV8 fuse bit.
[19:31:51] <Horologium> bit 7 of the low fuse...from 0 to 1....0 is default and turns prescaler on to 8...1 turns prescaler off.
[19:32:04] <Horologium> or rather, sets it to 1 which means no dividing of clock.
[19:34:26] <kdehl> Oh, man. I'm scared. Can I brick it now?
[19:34:35] <kdehl> I read the low fuse by this command:
[19:34:37] <kdehl> avrdude -c stk500v2 -p ATMEGA1284P -P /dev/ttyACM0 -U lfuse:r:fuses.hex:i
[19:34:57] <kdehl> I got a text file (fuses.hex) with the following two lines:
[19:34:58] <kdehl> :01000000629D
[19:34:59] <kdehl> :00000001FF
[19:35:52] <kdehl> No, wait...
[19:38:05] <creep> haha yea simplest parallel port programmers
http://my.opera.com/CrazyTerabyte/blog/2007/10/26/first-contact-with-atmega8-microcontroller-part-2
[19:38:23] <Horologium> -U lfuse:r:con:r -U hfuse:r:con:r -U efuse:r:con:r
[19:38:37] <Horologium> use those -U entries instead of yours.
[19:39:36] <Horologium> creep, yeah. I have an stk200 type like that one on there...without any resistors..
[19:39:39] <Horologium> it works.
[19:40:06] <creep> :)
[19:40:13] <creep> what about 3.3V ?
[19:40:16] <kdehl> Horologium: Doesn't that overwrite the 'con' file several times?
[19:40:23] <Horologium> con is console
[19:40:25] <Horologium> prints them
[19:40:51] <Horologium> creep, when I made it I was doing everything at 5V, so, no problem.
[19:40:58] <kdehl> Hm. It doesn't. It saves the values into a file called con. Weird.
[19:41:15] <Horologium> odd.
[19:41:17] <kdehl> I have version 5.11.1
[19:41:21] <Horologium> so, use 3 different filenames then.
[19:41:21] <kdehl> Should be decent.
[19:41:26] <kdehl> Yeah.
[19:41:44] <kdehl> But I only need lfuse, don't I?
[19:42:05] <Horologium> yeah.
[19:42:11] <creep> Horologium<< i am always shot with connectors, mostly i prefer none ;/ if i have to i just pick the gold connectors like ones used in PCs
[19:42:13] <Horologium> you can read just that one.
[19:42:55] <kdehl> Alright, now I need a hex editor. Embarrassingly enough I don't seem to have one installed...
[19:43:29] <Horologium> kdehl, hehe..ok, try this..
[19:43:38] <Horologium> -U lfuse:r:con:h
[19:43:48] <Horologium> gives it as a hex number.
[19:43:49] <Horologium> or
[19:44:01] <Horologium> -U lfuse:r:con:b
[19:44:06] <Horologium> gives it as a binary number.
[19:44:21] <Horologium> or,,,,wonder of wonders, read the man page and/or documentation.
[19:44:21] <kdehl> Ah!
[19:44:25] <kdehl> That's awesome!
[19:44:30] <kdehl> I did, I missed that part.
[19:44:44] <Horologium> big section under -U
[19:45:02] <Horologium> most of a whole printed page in the linux man pages.
[19:45:03] <kdehl> Yes. That's how I found the last :i part.
[19:45:27] <kdehl> Oh well. That was easy.
[19:52:18] <kdehl> Okay, I'm lost again. It seems like the divisor is already turned off.
[19:52:20] <OndraSter> kdehl, on windows I use tiny and simple xvi32 :D
[19:52:25] <OndraSter> (hex editor)
[19:52:46] <kdehl> avrdude -c stk500v2 -p ATMEGA1284P -P /dev/ttyACM0 -U lfuse:r:lfuse:b && cat lfuse
[19:52:48] <Horologium> what is that bit set to?
[19:52:54] <kdehl> And I get: 0b1100010
[19:53:24] <kdehl> According to the manual bit 7 is CLKDIV8, 0 is default value.
[19:53:52] <Horologium> yes..that's what I see too.
[19:54:11] <kdehl> That's odd. I've never touched it.
[19:55:21] <Horologium> haha.
[19:55:25] <Horologium> no leading zero.
[19:55:30] <Horologium> how many digits are there?
[19:55:33] <kdehl> Ohhh!
[19:55:39] <kdehl> Haha. You're right.
[19:58:07] <kdehl> Argh.
[19:58:14] <kdehl> Shouldn't I be able to just do:
[19:58:16] <kdehl> avrdude -c stk500v2 -p ATMEGA1284P -P /dev/ttyACM0 -U lfuse:w:lfuse:b
[19:58:31] <kdehl> When I've changed the file into: 0b11100010
[19:58:32] <kdehl> ?
[19:58:38] <Horologium> ummm...
[20:02:31] <kdehl> It's cool, I did
[20:02:31] <kdehl> avrdude -c stk500v2 -p ATMEGA1284P -P /dev/ttyACM0 -U lfuse:w:0x62:m
[20:02:33] <kdehl> instead.
[20:02:37] <kdehl> That worked. I think.
[20:03:42] <creep> what do you think of this ? ;>
http://www.fischl.de/usbasp/
[20:04:44] <kdehl> wth
[20:04:49] <kdehl> This made it _worse_.
[20:05:12] <Horologium> -U lfuse:w:0x99:m
[20:05:16] <kdehl> Not it's even misinterpreting scan codes in the original code.
[20:05:21] <kdehl> Oh.
[20:05:22] <Horologium> only, don't u8se 0x99
[20:05:29] <Horologium> you had the form right.
[20:05:37] <kdehl> Ah.
[20:06:01] <creep> i like this concept
http://fabiobaltieri.com/2011/09/02/usb-key-avr-programmer/
[20:06:18] <kdehl> Wait. 62 can't be right. There's no bit 7 set in that...
[20:06:24] <Horologium> creep, the usbasp is nice but doesn't work with some computers...it is using the bitbanged vUSB.
[20:06:37] <Horologium> and, bedtime...nighters.
[20:07:00] <kdehl> Night. And thank you for all the help!
[20:08:15] <kdehl> Man, I have screwed this up completely.
[20:09:15] <kdehl> No
[20:09:17] <kdehl> Hm.
[20:14:53] <nn7> ok, I think teraterm is fucking with me
[20:16:27] <nn7> it's translating what my microcontroller is sending
[20:16:38] <nn7> I can't have a terminal program that I can't trust
[20:19:32] <nn7> no, it's not
[20:19:37] <nn7> ok, I need help with this
[20:21:36] <nn7> this is my code:
http://pastebin.com/9xb8Um8Y
[20:22:24] <nn7> What it's giving me is "----" "reading eeprom" "inv" "PU" "Pp" "PZ"
[20:22:49] <nn7> but the U and p are high-bit ascii characters with accents and such
[20:22:58] <nn7> I've tried two different terminal programs and I get the same thing
[20:24:26] <kdehl> And it works.
[20:24:42] <kdehl> Man, that interrupt routine is really slow.... this bothers me a bit...
[20:29:22] <nn7> this is incredibly weird
[20:36:59] <nn7> ok, so here's what going on
[20:37:33] <nn7> If I sent a string of about 15 characters, noop for 15ms, then while(1); all the characters come through fine
[20:37:53] <nn7> if I set_sleep_mode and sleep_mode instead of the while(1), ALL 15 CHARACTERS come out differently
[20:38:35] * Horologium peeks in before going to the bedroom...
[20:38:37] <Horologium> hmmm
[20:38:52] <nn7> I don't see how this could go back in time and corrupt my serial stream
[20:39:00] <Horologium> sounds like the lib that's doing the usart comms is messed up.
[20:39:18] <Horologium> but, you didn't post that on your link up there...so, no clue.
[20:39:25] <Horologium> and, night,,again...........
[20:39:56] <nn7> here's the UART code, if you're still up.
http://pastebin.com/3bq420JU
[20:58:54] <tinygear> Hi, can anyone here help me with fuse bits? I think I may have messed something up :(
[21:02:29] <nn7> are you using avrstudio?
[21:02:29] <Tom_itx> do tell
[21:03:27] <tinygear> Thanks guys.
[21:03:29] <tinygear> I am using USBasp
[21:03:35] <tinygear> with avrdude
[21:04:06] <Tom_itx> and now you can't communicate with the chip?
[21:05:17] <tinygear> Nope, here is the command I initially sent
[21:05:18] <tinygear> http://pastebin.com/YY6rxKeU
[21:05:58] <tinygear> Notice the last few lines. So on one ATmega328, I hit 'y'. Everything froze after that. When I restarted everything, the chip wouldn't program.
[21:06:19] <tinygear> I tried a second 328, and hit 'n', it didn't freeze, and I got the result as shown in the link.
[21:06:31] <tinygear> But again, wasn't able to program it.
[21:06:40] <Tom_itx> -B32
[21:07:29] <tinygear> ?
[21:07:43] <tinygear> This is what I get when I try to program either of the two chips:
http://pastebin.com/UdLVmRzV
[21:07:47] <Tom_itx> do you have 2 dead chips now?
[21:07:50] <Tom_itx> or just one?
[21:07:54] <tinygear> Seems 2
[21:08:17] <tinygear> For one I types 'y', the other 'n'. Neither work now.
[21:08:31] <Tom_itx> avrdude: initialization failed, rc=-1
[21:08:34] <Tom_itx> can't see the chip
[21:08:51] <tinygear> Yes, but it is plugged in the same way as before, when it was working.
[21:09:04] <tinygear> Nothing changed, except I have the crystal attached now.
[21:12:12] <tinygear> Any ideas? Really could use some help. Thanks.
[21:13:56] <Tom_itx> why did you select ext low freq crystal?
[21:14:44] <Tom_itx> do you have a crystal wired to it?
[21:14:49] <Tom_itx> if not, you need one now
[21:14:58] <Tom_itx> if those fuse settings were written
[21:15:21] <tinygear> A crystal? Yes, I have a16mhz crystal attached to it.
[21:15:34] <Tom_itx> that's not a low freq crystal
[21:15:40] <tinygear> Oh no!
[21:15:52] <Tom_itx> find a slow one if you can
[21:15:58] <tinygear> Ok
[21:15:59] <Tom_itx> like 1mhz
[21:16:02] <Tom_itx> or less
[21:16:09] <Tom_itx> maybe that will work
[21:16:10] <tinygear> Yikes, may not have
[21:16:17] <tinygear> Will check my parts
[21:17:03] <tinygear> 32,768 kHz?
[21:17:08] <tinygear> 32.768
[21:17:09] <Tom_itx> try it
[21:17:16] <Tom_itx> won't hurt to try
[21:17:24] <Tom_itx> leave the caps off for now
[21:17:29] <tinygear> Ok
[21:17:31] <tinygear> So straight to ground?
[21:17:35] <tinygear> both leads
[21:17:37] <Tom_itx> no
[21:17:44] <Tom_itx> across the crystal input pins
[21:17:50] <tinygear> Oh ok
[21:18:08] <Tom_itx> where was the 16Mhz one hooked to?
[21:18:24] <tinygear> The XTAL1 and XTAL2 pins
[21:18:29] <Tom_itx> k
[21:18:36] <Tom_itx> try the clock crystal there
[21:18:48] <tinygear> Yep, something seems to be working
[21:18:55] <tinygear> the program i had in it before is working
[21:19:06] <tinygear> blinking an led, much slower than before (as expected)
[21:19:16] <tinygear> but programming still isn't working
[21:19:21] <Tom_itx> change the fuse settings now to something more reasonable
[21:19:47] <Tom_itx> add the -B32 to the avrdude line and try it
[21:19:53] <Tom_itx> may not help
[21:20:07] <tinygear> what does -B32 do?
[21:20:32] <Tom_itx> add delay
[21:21:00] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/usbtiny_programmer/testing_index.php
[21:21:04] <Tom_itx> read the bottom of that page
[21:21:51] <tinygear> Cool
[21:22:16] <tinygear> I tried, and am getting this:
http://pastebin.com/1AdHBK14
[21:23:04] <Tom_itx> dunno about your programmer
[21:23:10] <Tom_itx> says you need an updated firmware
[21:23:31] <tinygear> It always says that, but always works
[21:23:39] <Tom_itx> i'm not crazy about bigbanged usb programmers
[21:23:52] <tinygear> The program is clearly working, I just can't reprogram
[21:23:54] <Tom_itx> breadboard?
[21:23:59] <Tom_itx> check your wiring closely
[21:24:25] <tinygear> Ok, I'll rewire even
[21:24:37] <Tom_itx> do a meter test on all the wires
[21:24:44] <Tom_itx> from chip to end
[21:24:48] <Tom_itx> not from wire to wire
[21:25:11] <tinygear> Ok, but everything seems to be fine, this setup is programming other MCUs without a problem
[21:25:26] <Tom_itx> breadboards are prone to fail
[21:29:53] <tinygear> Tom_itx: Same problem, even after checking and reiring
[21:29:57] <tinygear> rewiring*
[21:32:06] <nn7> I think I've determined that I'm running out of memory on this chip and it's doing weird things
[21:32:44] <Tom_itx> tinygear, don't mess with any more fuses until you can determine you have a reliable working programmer
[21:32:48] <Tom_itx> for starters
[21:33:10] <tinygear> Ok, though I have been working with this programmer for months
[21:33:15] <Tom_itx> did you set the fuses on the first one the same?
[21:33:41] <tinygear> Good question, it may be slightly different because I hit "y" instead of "n"
[21:33:43] <tinygear> Let me try
[21:36:31] <tinygear> No luck
[21:36:37] <tinygear> but the led blinking is working
[21:36:44] <tinygear> How odd
[21:39:34] <tinygear> Any other ideas Tom_itx ? Thanks a lot for your kind help
[21:48:44] <nn7> alright, I'm fairly certain that sleep mode on the attiny2313 is fucked up
[21:51:51] <tinygear> Tom_itx: Do you think getting a 1Mhz crystal would help?
[22:01:47] <nn7> I have simple code that turns a motor on an off (a buzz), puts the AVR to sleep, then buzzes once more when it wakes up
[22:02:11] <nn7> if I use the sleep mode, the second buzz goes on forever once the AVR is woken up
[22:02:28] <nn7> if I don't use the sleep mode, it does two more short buzzes
[22:02:45] <nn7> I've tried "set_sleep_mode" and setting the registers myself
[22:25:10] <Tom_itx> tinygear, you could try it
[22:25:14] <Tom_itx> no guarantees
[22:25:32] <Tom_itx> i don't think you're so bad off with the fuses yet
[22:25:42] <Tom_itx> not as bad as most are that brick an avr
[22:25:58] <tinygear> Tom_itx: I agree
[22:26:12] <tinygear> I tried my last 328, set the fuses properly this time, and it works
[22:26:26] <tinygear> but I have two that are useless at the moment, which I really need
[22:26:49] <Tom_itx> http://www.engbedded.com/fusecalc/
[22:26:53] <Tom_itx> a handy tool
[22:27:50] <Tom_itx> you were able to program another with your programmer?
[22:28:08] <tinygear> Tom_itx: Yep
[22:28:12] <Tom_itx> then you need to figure out a clock source the bad avr's like
[22:28:17] <Tom_itx> so you can recover them
[22:28:34] <tinygear> Ok, but there are so many possibilitie
[22:28:41] <Tom_itx> if you try the clock crystal, you will need to slow your programmer way down
[22:28:45] <tinygear> Do I use a function generator or something?
[22:28:49] <Tom_itx> a 1mhz may do the trick
[22:29:29] <tinygear> Hmm ok
[22:29:35] <Tom_itx> the spi needs to be 4x the clock rate
[22:29:56] <Tom_itx> err vice versa
[22:30:17] <tinygear> Yes, I found that out too
[22:30:27] <Tom_itx> read that link i posted about -B
[22:30:32] <Tom_itx> that explains it
[22:30:40] <tinygear> Yep, very nicely explained
[22:30:53] <tinygear> But what I don't understand is, is there a way to set it when programming?
[22:31:06] <tinygear> To match what I need?
[22:31:08] <Tom_itx> set what?
[22:31:15] <tinygear> That speed
[22:31:24] <Tom_itx> the -B
[22:31:51] <tinygear> So if I am using my 32 kHz crystal
[22:31:57] <Tom_itx> that's why i suggested -B32
[22:32:16] <Tom_itx> you may have other issues with the crystal not oscillating too
[22:32:20] <tinygear> Yes, but it didn't seem to work
[22:32:32] <Tom_itx> so get a regular 1Mhz one and try it
[22:32:34] <tinygear> Well, the crystal seems to be working ecause of the led blinkng
[22:32:40] <Tom_itx> ok
[22:32:41] <tinygear> Yes I will try that
[22:34:06] <Tom_itx> my programmer has a recovery clock on it
[22:34:12] <Tom_itx> for such things
[22:34:39] <Tom_itx> possibly might not work on that if you selected a slow crystal though
[22:34:44] <Tom_itx> haven't tried that
[22:35:48] <tinygear> Alright. But would a function generator work?
[22:36:01] <Tom_itx> probably
[22:36:04] <tinygear> So that I could try variable frequencies?
[22:36:30] <tinygear> But you still suggest trying 1 mhz crystal first?
[22:36:38] <Tom_itx> doesn't matter
[22:36:51] <Tom_itx> if you already have that, give it a try
[22:37:10] <Tom_itx> figure out which xtal pin is input
[22:37:26] <Tom_itx> data sheet tells that
[22:37:31] <Tom_itx> probably xtal1
[22:38:12] <tinygear> dont you need xtal1 and xtal2?
[22:38:22] <tinygear> and i heard you could use another avr as a clock source
[22:38:26] <Tom_itx> not if you are providing a ttl clock source
[22:38:33] <Tom_itx> you can use another avr
[22:38:40] <Tom_itx> anything that gives you a frequency
[22:38:55] <Tom_itx> just 'blink' an led real fast
[22:39:01] <Tom_itx> and use that pin
[22:39:51] <tinygear> Ah I see, ok I can try that.
[22:42:17] <tinygear> Tom_itx: So that would mean a delay of 1 us?
[22:42:22] <tinygear> TO get 1 mhz?
[22:54:29] <tinygear> Anyway, thanks for your help Tom_itx
[22:54:35] <tinygear> Really appreciate it
[23:34:21] <creep> what is the point of all those different parallel port pinouts ?
[23:35:22] <creep> bsd seems the easiest to wire up maybe, but dapa is the most logically correct
[23:38:49] <Casper> different pinout because different persons did it
[23:38:58] <Casper> before it became more standard
[23:41:44] <creep> Casper<< what came stadard ?:) usb ? (none) ?
[23:43:05] <Casper> dapa for pport
[23:43:31] <creep> o yea, so i guessed the best one ?
[23:43:59] <creep> what is the point of stk200 anyway ?
[23:44:24] <creep> tieing loopbacks
[23:45:09] <creep> and skipping d6
[23:45:26] <creep> just to not be compatible with bsd
[23:45:47] <Casper> probably for autodetection
[23:46:26] <creep> device id can be read, and verified, want more?
