Back
[04:15:09] <Fleck> so, anyone here who used bootloader and interrupt vector functions in bootloader and flash?
[04:26:59] <johnwalkr> haha
[04:27:10] <johnwalkr> i think i am having problems related to that right now
[04:28:01] <Fleck> johnwalkr: what's your problem?
[04:28:24] <johnwalkr> hard to describe, i’m just sitting down to troubleshoot now
[04:28:44] <johnwalkr> i was previously reading an analogue value when requested by an i2c command
[04:29:24] <johnwalkr> but now i am reading values constinuously and averaging them and then sending the value when requested
[04:30:10] <johnwalkr> so i’m using ISR(ADC_vect)
[04:30:40] <johnwalkr> not sure if it is even being called because i’m getting weird data
[04:31:55] <johnwalkr> oh, made these changes at the same time as switching bootloaders
[04:31:59] <johnwalkr> which was probably a bad move
[04:32:36] <Fleck> MCUCR?
[04:35:48] <johnwalkr> not setting anything MCUCR
[04:35:58] <johnwalkr> isn’t that for using external things to cause interupt?
[04:36:47] <Fleck> well, I don't really understand, but datasheet says "moving" vectors or smthn like that
[04:39:22] <johnwalkr> i think i found an overflow problem for my issue
[04:39:49] <johnwalkr> so probably nothing to do with interrupts at all. bad on me for changing the bootloader at the same itme as a major change though
[04:41:43] <Fleck> meh
[04:42:15] <Fleck> I have 8K bootloader space, that is empty, and using vector function in flash... it never gets called :/
[04:43:05] <Fleck> http://paste.opensuse.org/99490354 << :/
[04:43:43] <Fleck> if bootrst fuse in unprogrammed, working ok, or, if bootloader space unallocated
[04:45:02] <johnwalkr> i can’t think of a reason why :/
[04:45:08] <johnwalkr> i don’t know very much about them though
[05:21:51] <edmont> hi
[05:22:47] <edmont> does anyone have experience with AVR tools under Android?
[05:23:15] <edmont> i've seen this guy using his phone to program devides and i'd like to do the same:
[05:23:16] <edmont> http://www.youtube.com/watch?v=XMc7agVtfTU
[05:23:36] <Epsilon-Auriga> I got avrdude to work on my tablet.
[05:23:46] <Epsilon-Auriga> and Tom_itx's programmer connected and worked.
[05:24:27] <Epsilon-Auriga> had to do a lot of crazy shit to avrdude to get it to compile and work though.
[05:24:40] <Epsilon-Auriga> never did get gcc to compile for it though.
[05:47:56] <antto> Fleck did you check my bootloader?
[05:48:35] <Fleck> just scrolled trough :D
[05:49:17] <Fleck> *through
[05:51:59] <antto> well, i can assure you that the interrupt in my bootloader surely works
[05:52:11] <antto> i can tell you the fuse settings for the chip if you want too
[05:53:24] <Fleck> bootsz0:1 are set. bootrst is set :D
[05:53:31] <Fleck> all I need to know, I guess
[05:54:06] <antto> Fleck
http://wiki.openmusiclabs.com/wiki/x0xb0x
[05:54:10] <antto> scroll down a bit
[05:54:31] <antto> the only diff is that BOD is 2.7 because we had problems at 4.3
[05:56:45] <Fleck> antto: maybe this:
http://im9.eu/picture/ic2541
[05:57:55] <Fleck> doesn't explain why it's not working for me thou
[05:59:47] <antto> the some interrupts might not work depending on the lockbits?!
[06:00:18] <antto> iirc, we are using 0x0F <- to lock the bootloader
[06:00:22] <Fleck> No, I marked sentence :D
[06:00:57] <antto> oh
[06:01:13] <antto> wtf does it even mean
[06:02:05] <Fleck> if your timer0 is taking too long to reenable interrupts, timer3_compa may never be called :D
[06:02:28] <Fleck> timer0 has higher priority thant timer3
[06:02:35] <Fleck> *than
[06:02:41] <antto> oh boy
[06:02:46] <antto> that makes sense then
[06:03:47] <Fleck> I mean not that timer0/3 itself, but timer0 and timer3 interrupts have different priorities
[06:04:41] <Fleck> sorr for my english, heh
[06:04:41] <antto> yeah yeah
[06:04:56] <antto> i also read last night about priority, but it didn't ring any bell
[06:05:06] <Fleck> :)
[06:05:08] <antto> lower numbers got more priority..
[06:05:12] <Fleck> yep
[06:05:25] <antto> so then, what i use timer0 for, i should move that to timer2 (which is 8bit too)
[06:05:35] <antto> and use timer1 for my 16bit job
[06:05:44] <Fleck> yep, that could work! :D
[06:06:33] <Fleck> I think that's why they are in such a strange order... so you can make things right!
[06:06:50] <antto> yes, now with this small detail, it all makes sense
[06:09:36] <Fleck> keep me updated antto, still, not explaining why it's not working here! :D
[06:09:58] <antto> tbh, i kinda gave up on this
[06:10:22] <Fleck> :D
[06:10:34] <Fleck> never ever give up, that's how you learn!
[06:10:37] <antto> the issue i was trying to fix.. i probably better fix it some other way
[06:10:58] <antto> no, this is good to know, because i still might want to use another timer
[06:46:21] <rigid> does anyone know how much of a problem it is to use an avr at it's absolute maximum operating voltage of 6V?
[06:46:43] <Fleck> one diode problem :D
[06:46:52] <antto> got eggs?
[06:47:41] <rigid> Fleck: diode to limit voltage?
[06:47:52] <antto> i guess to drop the voltage
[06:47:54] <Fleck> voltage drop...
[06:47:56] <Fleck> yeah
[06:48:07] <rigid> wouldn't that waste energy?
[06:48:16] <Fleck> sure
[06:48:27] <rigid> i'm deadbugging a SOIC8, so space is also an issue
[06:48:55] <rigid> i want to use 6V so I can use 4 coin cells instead of 3 to increase operating time
[06:49:21] <rigid> the datasheet says, "operation beyond those values can cause trouble" but 6V is absolute maximum
[06:49:45] <antto> don't risk it IMHO
[06:50:24] <rigid> i wonder how the internal RC oscillator behaves when the voltage drops to 2.7V
[06:50:38] <rigid> antto: hm, i'll do... but I expect trouble :)
[06:51:24] <rigid> hm... i'll just choose a longer spring for the battery holder, so I can go with 3 cells if there's failure
[06:51:36] <rigid> i got tons of tiny11 so I can burn some
[06:51:43] <antto> muhaha ;]
[06:51:52] <rigid> Fleck: antto: thanks
[07:02:05] <twnqx> rigid: use an evil switching rgulator if you can afford a few extra euros. i have one that generates 5V from ~3V to 26V input :P
[07:02:42] <rigid> $ is not the problem but space, it's all deadbug
[07:02:59] <rigid> SMD LED, SMD resistor, SOIC8 and pushbutton
[07:03:04] <rigid> and some epoxy :)
[07:03:11] <twnqx> ah, space might be troublesome. it requres a pretty big coil (mine is 12mmx12mm)
[07:03:28] <rigid> yeah
[07:03:52] <twnqx> might be oversized (currentiwse) though
[07:04:04] <twnqx> i think i dimensioned it for 1.5A of power
[07:05:12] <rigid> yep... 1.5A with 18mAh button cells wouldn't last too long ;)
[11:25:21] <dnia> I have 100 pin atsam3u4c, it has one large circle and a small circle on the opposite corner, which one indicates the pin 1?
[11:26:21] <dnia> or none of them and just refer the printed text on the mcu?
[11:29:07] <jadew> the small one
[11:29:32] <jadew> does it look like this?
http://www.atmel.com/Images/banner_sam3u.jpg
[11:30:33] <dnia> yeah but I dont have the very little one the right corner
[11:30:58] <dnia> I have large one on the upper right corner and small one on the left bottom corner
[11:31:51] <jadew> take a picture, it's possible the shape of the 1 corner is different than the others as well
[11:40:43] <dnia> jadew, I don't have my phone with me, I used my webcam but photo is not good quality
http://i39.tinypic.com/33uwg9u.jpg
[11:41:46] <jadew> it's clearly the one with the small dot
[11:42:01] <dnia> is there such rule that if "atmel" text on the MCU is on the orientation that I can read, is the left upper corner the first pin?
[11:42:03] <jadew> as I said earlier, the corner might be different then the others
[11:42:05] <jadew> and it is
[11:42:16] <jadew> there's not
[11:42:38] <dnia> hmm ok
[11:42:58] <dnia> corners seems the same
[11:43:08] <dnia> thanks for the help
[11:43:17] <jadew> the one with the dot is clearly shaved
[11:43:19] <dnia> what is the purpose of the large one?
[11:43:32] <jadew> dnia, I don't know, probably a manufacturing artifact
[11:44:29] <dnia> yeah now I notice that corner is different
[11:44:33] <dnia> :)
[11:45:27] <dnia> the pin 1 is the left side of the small dot, right? counter clock wise?
[11:45:49] <jadew> the datasheet will tell you for sure
[11:47:46] <jadew> that board looks new, how come it's not yours?
[11:48:05] <dnia> jadew, could you please look at this one
http://i39.tinypic.com/2h2fn7t.png here is the layout
[11:48:19] <jadew> oh, it is yours, the chip is not soldered yet
[11:48:22] <dnia> the dot is on the left bottom corner
[11:48:27] <dnia> no I have not soldered it yet
[11:48:42] <jadew> that's not the page you're looking for
[11:50:15] <dnia> if you have a fast internet, could you please look at the page 1152 on
http://www.atmel.se/Images/doc6430.pdf
[11:51:03] <dnia> that page shows the LQFP package, the next pages are for a different packages
[11:51:59] <dnia> here is smaller version (summary) and the layout is at page 52 on
http://www.atmel.se/Images/6430s.pdf
[11:52:04] <dnia> it is 1.5 MB
[11:54:10] <dnia> jadew, I found it on a different page, thanks a lot for the help
[11:54:21] <jadew> np, which page?
[11:54:33] <dnia> page 9 on
http://www.atmel.se/Images/6430s.pdf
[11:54:55] <jadew> there it is, I was on that page initially, but I missed it
[11:55:22] <jadew> it's actually on page 12
[11:55:30] <jadew> you said it's a 100 pins LQFP, no?
[11:56:04] <dnia> yeah, I told the number as google shows the number when I scroll down
[11:56:18] <dnia> maybe it is not corresponding the one that adobe shows
[11:56:47] <dnia> oj yes it was wrong,
[11:57:16] <dnia> *I was wrong :)
[11:58:10] <dnia> thanks a lot again for your time and the help
[11:58:17] <jadew> np
[17:19:09] <jadew> best teardown ever:
http://www.youtube.com/watch?v=NzwqxQtKwao
[17:19:10] <jadew> YouTube: Rigol DS1074Z Teardown
[17:19:20] <jadew> Casper
[17:19:40] <jadew> I couldn't stop laughing
[17:28:07] * Casper pokes jadew
[17:28:18] <Casper> I would have needed your help earlier this week
[17:28:26] <Casper> I was going insane at work
[17:28:38] <jadew> oh, how come?
[17:28:46] <Casper> I had like 15 laptops and 6 tower in the shop
[17:28:49] <Casper> to repair
[17:28:54] <Casper> mostly windows and virus
[17:28:56] <jadew> haha
[17:29:32] <jadew> I have two laptops from family & friends that I need to check out as well, they've been gathering dust for about two weeks
[17:29:45] <Casper> you're slow
[17:29:56] <Casper> I'm currently finishing the jobs
[17:30:13] <Casper> so I'm only working on 3 laptop and 2 towers at the same time
[17:30:40] <jadew> well, I have to get people to stop asking me to do this somehow
[17:30:45] <Casper> this morning I was working on 7 laptop and 2 computers at the same time
[17:31:48] <jadew> check out that teardown, it's painful :P
[17:32:29] <jadew> it's probably the first one of the DS1000Z so at least that's a plus
[17:33:24] <Casper> will check, once at home
[17:33:27] <Casper> I'm at work
[17:33:33] <jadew> ah
[17:33:34] <Casper> taking a small mental break
[17:34:19] <jadew> I'm trying to cope with the fact that the stuff I ordered from china will come much later than I expected
[17:34:34] <jadew> apparently it's the new freaking year, starting with today
[17:34:37] <N2TOH> yeah print out that XKCD or the oat meal commic about being a local computer expert
[17:35:00] <jadew> lasts till 10th the next month
[17:35:29] <jadew> they must party pretty hard'
[17:35:57] <N2TOH> http://theoatmeal.com/blog/fix_computer
[17:36:29] <N2TOH> http://theoatmeal.com/comics/computers
[17:37:32] <N2TOH> AH! here it is, best to print this one out for them then risk dealing with other peoples printer issues,
[17:37:34] <N2TOH> http://xkcd.com/627/
[17:37:57] <sabesto> anyone used a jtagice3 with a mac?
[17:38:12] <jadew> N2TOH, that second link is so freaking true...
[17:38:25] <jadew> sad part is I don't enjoy fixing computers
[17:38:32] <sabesto> os thinks its found a camera when i plug it in
[17:38:47] <jadew> lol
[17:38:59] <jadew> well, get on skype and start chatting!
[17:39:13] <jadew> video chatting!
[17:40:27] <sabesto> where do i plug the jtag connector then?
[17:40:31] <N2TOH> and the computer still keeps asking for drivers?
[17:40:31] <sabesto> lick on it?
[17:41:14] <Casper> so not true for linux
[17:41:26] <sabesto> if that was for me, no
[17:42:22] <Casper> it's more like: step 1: what the hell have you fucked again? Undo it! step 2: hang yourself :D
[17:43:48] <jadew> next time I'll install linux on my pc, I'm gonna make a video
[17:44:03] <jadew> it's hilareous every single time
[17:44:28] <Casper> why? too easy? too fast?
[17:44:38] <N2TOH> HAHAHAHAHAHAAAH!!!!!!
http://xkcd.com/1305/
[17:44:38] <jadew> it never works how it should
[17:44:55] <jadew> for example, my current linux mint install starts up properly only from time to time
[17:45:13] <jadew> so I have to reboot the pc several times until it doesn't crash while booting up
[17:48:29] <jadew> then there's setting up the dispays, which never seems to work like it did the last time
[17:49:03] <jadew> http://dumb.ro/files/fail1.jpg
[17:49:05] <jadew> http://dumb.ro/files/fail2.jpg
[17:49:37] <jadew> that sort of thing
[17:50:12] <N2TOH> lol
[17:50:19] <N2TOH> been there done that
[17:57:16] <jadew`> lol @ the last xkcd post
[18:10:53] <jadew`> found another one of my favourites, I actually reported this bug:
http://bug-attachment.xfce.org/attachment.cgi?id=4023
[18:11:00] <jadew`> that's the start menu :/
[18:12:46] <jadew`> I just noticed that it's been 2 years since I reported that bug and it's still marked as "
[18:12:49] <jadew`> "New"
[20:56:39] <Brittany_> when calling ISR(USART0_RX_vect), the actions are not being committed, even though I'm actually observing an LED toggle to acknowledge RX of USART0.
[20:56:49] <Brittany_> So for some reason the ISR is not occuring, even though the conditions for it are.
[20:56:54] <Brittany_> Any clue, anyone?
[20:57:38] <Tom_itx> check the name spelling in the io.h file
[20:57:43] <Tom_itx> for the interrupt
[20:57:48] <Tom_itx> then sei()
[20:57:50] <Tom_itx> to enable them
[20:58:21] <Tom_itx> that's 2 clues
[20:59:13] <Brittany_> Hey Tom
[20:59:19] <Brittany_> Can you do me a favour and punch me in my fucking clueless head.
[20:59:22] <Brittany_> I didn't enable interrupts.
[20:59:26] <Brittany_> And I'm wondering why interrupts aren't working.
[20:59:36] <Tom_itx> naw i wouldn't do that
[21:00:05] <Tom_itx> it's generally one or the other
[21:01:35] <Brittany_> ah.. though it hasn't helped..
[21:01:39] <Brittany_> unfortunate.
[21:02:47] <Brittany_> the LED blinks, the board receives its information and nothing comes of it. Odd.
[21:02:54] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/avr/rs232_rx_test/
[21:02:57] <Tom_itx> that uses interrupts
[21:06:27] <Brittany_> mine takes the same structure.
[21:06:31] <Brittany_> I suppose I'm just doomed.
[21:06:47] <seldon> Interrupts enabled in UCSRnB?
[21:09:20] <Brittany_> it isn't.
[21:09:23] <Brittany_> thanks seldon, I'll try this.
[21:13:35] <Brittany_> nope.
[21:13:38] <Brittany_> UCSR0B |= _BV(RXCIE0);
[21:13:47] <Brittany_> setting ISR(USART0_RX_vect) to handle a few basic routines
[21:13:51] <Brittany_> and sei(); in main program loop.
[21:14:07] <Brittany_> compiles fine, transmits data, no love.
[21:16:33] <seldon> The baud rates of sender and receiver match?
[21:17:23] <seldon> Same question for frame format.
[21:17:41] <seldon> Is the init sequence complete, is basically what I'm asking.
[21:18:40] <seldon> There should be an example sequence in your MCU's datasheet.
[21:18:44] <Brittany_> yes sir.
[21:18:55] <Brittany_> hm.
[21:19:02] <Brittany_> this might be a little too much for a school project, methinks.
[21:19:21] <Brittany_> We're starting to get into territories beyond my understanding.
[21:22:05] <Tom_itx> hang in there... you'll get it
[21:22:16] <seldon> baud rate means how quickly data is transmitted. If one side speaks faster than the other listens, there are problems. Frame format means how the data is split into packets -- number of start bits, stop bits, and how many bits in between to send/expect.
[21:22:26] <seldon> Both have to match.
[21:22:37] <seldon> What MCU are you using?
[21:22:42] <Brittany_> atmega 644p
[21:22:51] <Brittany_> I appreciate your help guys. :)
[21:22:59] <Brittany_> This is an interesting issue.
[21:24:36] <seldon> Okay, the relevant part of the datasheet is chapter 17 (page 171 and following). An example init sequence is in 17.6 on page 178.
[21:26:12] <Brittany_> probably another version
[21:26:15] <Brittany_> chapter 17 for me is SPI
[21:26:23] <Brittany_> I'm definitely interested in usart, heh.
[21:26:26] <Tom_itx> get a current one
[21:26:51] <seldon> http://www.atmel.com/images/doc7674.pdf is what I have here. If 17 is SPI, USART is probably 18 in yours.
[21:29:37] <seldon> I wouldn't be surprised if avr-gcc had a combined UBRRn alias for UBRRHn and UBRRLn (which are the high and low byte of the baud rate, respectively).
[21:30:39] <seldon> So you can probably just say UBRR0 = baud_rate; (if you're using usart0)
[21:30:39] <Tom_itx> i think it does
[21:31:06] <Tom_itx> http://www.wormfood.net/avrbaudcalc.php
[21:33:36] <Brittany_> ubbr0 undeclared.
[21:33:38] <Brittany_> noooo
[21:33:45] <seldon> UBRR0, not UBBR0
[21:33:50] <seldon> usart baud rate register
[21:33:50] <Brittany_> *sigh*
[21:33:53] <Brittany_> I am a tired woman.
[21:34:28] <Brittany_> I'm afraid still, nothing yet.
[21:34:55] <Brittany_> so now I have a ISR(USART0_RX_vect) handler
[21:35:14] <Brittany_> a UCSR0B |= _BV(RXCIE0); and UBRR0 = BDRATE_BAUD (9600);
[21:35:17] <Brittany_> declaration..
[21:35:25] <Brittany_> and I've set interrupts.
[21:35:54] <seldon> And the frame format in UCSR0C matches the sender's?
[21:36:47] <Brittany_> I'm not sure.
[21:36:50] <Brittany_> I don't see why not.
[21:37:02] <seldon> What does the sender use?
[21:37:18] <seldon> Or: what is the sender?
[21:37:30] <Brittany_> I'm sorry, I'm not sure.
[21:37:43] <Brittany_> I know that there's no flow control, no parity, one stop bit.
[21:37:47] <Brittany_> runnning at 9600 baud
[21:38:05] <seldon> Do you know how long the payload is?
[21:38:25] <Brittany_> no.
[21:38:32] <seldon> Then we'll brute-force it.
[21:38:42] <seldon> Ther are only a couple combinations.
[21:38:48] <Brittany_> the background behind this is that it's skeleton code that's not well understood given to us by our professor with the directives "make it work."
[21:39:00] <Brittany_> Sorry if I'm a little ignorant.
[21:39:13] <Brittany_> Last year I couldn't even solder the damn AVR board together, at least we're this far.
[21:39:41] <Tom_itx> so make it work!
[21:39:51] <Brittany_> haha it'd be nice. :)
[21:40:08] <Brittany_> I'm just incredibly confused because the interrupt vector won't perform even if I set it to TX.
[21:40:13] <Tom_itx> he must know something is wrong
[21:40:29] <Tom_itx> they're separate vectors
[21:40:47] <Tom_itx> RX is 20 and TX is 22
[21:41:25] <Tom_itx> #define USART0_RX_vect _VECTOR(20)
[21:41:27] <seldon> If you want the TX vector to fire, you'll need to set TXCIE0 in UCSR0B. Anyway, look at 17.11.4 (or somewhere around 18.11.4) for the UCSRnC register description.
[21:41:33] <Tom_itx> #define USART0_TX_vect _VECTOR(22)
[21:41:58] <Tom_itx> in the io.h file
[21:41:59] <Brittany_> oh I'm aware Tom
[21:42:13] <Brittany_> I'm trying to handle this issue I have through interrupts.
[21:42:25] <Brittany_> I was trying to set up a TX interrupt but that's not going either.
[21:42:35] <seldon> I'd start with UCSR0C = _BV(UCSZ01) | _BV(UCSZ00);
[21:42:44] <seldon> That's 8 bit payload
[21:43:16] <seldon> But really you should check what the sender code uses and use the same.
[21:43:56] <seldon> If they use different clock sources, be mindful of it in the baud rate calculation.
[21:44:15] <Brittany_> this isn't working out.
[21:44:20] <Brittany_> to be honest.
[21:44:28] <Brittany_> My issue is that I'm trying to get a boost converter piece of hardware working.
[21:44:58] <Brittany_> the program constantly attempts to maintain PWM in the program loop for any load changes to match the desired voltage output.
[21:45:05] <Brittany_> i've got that part down just fine!
[21:45:21] <Brittany_> the part that's making it difficult is being able to suddenly type a number and have that be our new set point voltage.
[21:46:03] <Tom_itx> are you storing the number in the OCRx register for the pwm?
[21:46:58] <Brittany_> yeah.
[21:48:56] <seldon> 8 bit or 16 bit?
[21:50:11] <Brittany_> 8 bit
[21:50:16] <Brittany_> counter 2.
[21:51:46] <seldon> I'd probably just use SPI. It's much less hassle because synchronisation is unnecessary, and it doesn't sound like you have huge chunks of data to transfer.
[21:52:47] <Brittany_> heh.
[21:53:03] <Brittany_> The issue here lies in my lack ofu nderstanding of it.
[21:53:39] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/how_to/atmega168/mega168_howto_main_index.php
[21:53:44] <Tom_itx> basics
[21:54:25] <seldon> Well, usart depends a lot on timing. That's good if you can manage it because speed, but it means that both sides have to use roughly the same timing. Less than roughly, really.
[21:55:09] <seldon> In SPI the sender controls the speed - sets its bit on the data line, then toggles the clock line to let the receiver know there's data. As long as the sender doesn't do it too quickly, that will always work.
[21:55:19] <Tom_itx> Brittany_, also
http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_usart_index.php
[21:55:21] <Tom_itx> and
[21:55:25] <Brittany_> I just don't see why I can't have something that'd say "signal? enter this loop."
[21:55:32] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_usart_interrupt_index.php
[21:55:38] <seldon> Because phsyics.
[21:55:50] <Brittany_> It seems incredibly convoluted. I'm sending data via my host PC, I want to just enter a loop on the condition I enter a command.
[21:55:59] <Tom_itx> take the time to read those maybe it will help a bit
[21:56:38] <Tom_itx> that first code i showed you waits for the pc to enter a character
[21:57:15] <seldon> Because physics suck. You're interfacing with the analog world here, and aren't there many hoops to jump through to get back from there to sanity.
[21:59:08] <seldon> Your problem, in general terms, is that a flip-flip has no understanding of "data."
[22:00:45] <seldon> So to get back to a world of just sending data somewhere, you have to follow protocol -- in this case usart. That means listening and sending at the same speed, in the same format. If you don't know what speed and format your PC is sending, you have to find out.
[22:01:12] <seldon> It's probably somewhere in the settings of whatever client program you're using.
[22:02:24] <seldon> And be glad you're not trying to speak ethernet or USB or something.
[22:04:53] <Brittany_> mhm.
[22:04:56] <Brittany_> I'm running out of time.
[22:05:05] <Brittany_> I'm literally just grabbing at flecks of code and hoping it works.
[22:05:20] <Tom_itx> waited too long to come here and ask ehh?
[22:06:51] <Brittany_> haha.
[22:06:54] <Brittany_> I've had the flu.
[22:07:07] <Brittany_> Just trying to get another 'make our code work' project working from our university.
[22:07:15] <PoppaVic> the typing fingers were too busy sneezing and coughing
[22:07:29] <Brittany_> I don't understand the format. I thought the best way to learn was to define your own problem and implement it.
[22:07:38] <Brittany_> So far my degree has consisted of "here's a thing we built. debug it."
[22:07:49] <Tom_itx> heh
[22:07:58] <Tom_itx> that's kinda what we do here
[22:08:00] <PoppaVic> ahm so yer a tech
[22:08:09] <Brittany_> As a result, rather than understanding a communications protocol... I tend to understand a small section of where it can mess up.
[22:08:10] <PoppaVic> Blame the en-gi-neers
[22:08:16] <Tom_itx> PoppaVic where did you come from?
[22:08:22] <Tom_itx> haven't seen you around
[22:08:32] <PoppaVic> I was down the hall & around the corner - all day ;-)
[22:08:56] <PoppaVic> Actually tried to enjoy the first "second day off" in months
[22:21:50] <Brittany_> what is 'URSEL'
[22:21:54] <Brittany_> I can't find the equivalent for my chip
[22:23:31] <tzanger> PoppaVic: whoa you wandered over from ##c
[22:23:41] <Tom_itx> Brittany_ where do you see it?
[22:23:44] <Brittany_> I've got UMSELn0
[22:23:52] <Brittany_> on your code, tom.
[22:25:10] <Tom_itx> which code?
[22:25:31] <Brittany_> http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_usart_index.php
[22:25:44] <Tom_itx> oh, that's Dean's article not mine
[22:26:58] <PoppaVic> tzanger: well, I bought an arduino; more avr's are incoming - sounded like a plan of sorts. Besides, ##C is just for thrashing lazy students ;-)
[22:27:05] <Tom_itx> The URSEL bit does not exist in all AVR models; check your chosen AVR's datasheet.
[22:27:11] <Tom_itx> he mentions that as well
[22:27:21] <tzanger> PoppaVic: haha
[22:27:42] <Tom_itx> so if it's not there, ignore it
[22:29:05] <Brittany_> hm.
[22:29:14] <Brittany_> so even following what seem to be basic instructions, this isn't working.
[22:32:04] <Brittany_> I have a feeling I'm not solving this tonight.
[22:32:08] <Brittany_> Night guys, thanks for the help
[22:32:59] <Tom_itx> np
[23:40:54] <clixxIO> Just wondering, are there any event frameworks for AVR yet?
[23:42:46] <clixxIO> I started writing one..
[23:43:31] <clixxIO> this is one with a simple timer callback:
https://github.com/clixx-io/clixx.io/blob/master/eventframework/timer.cpp
[23:45:36] * PoppaVic chortles
