Back
[10:41:29] <chupas> https://www.youtube.com/watch?v=la2qCPgK71Y
[10:41:36] <chupas> what language is this?
[10:42:01] <chupas> i thought hey said american TV was riskay
[10:42:28] <Lambda_Aurigae> korean
[10:42:34] <Lambda_Aurigae> at least, the writing is.
[10:42:47] <Lambda_Aurigae> the women look korean
[10:42:57] <chupas> ok then!
[10:43:38] <Lambda_Aurigae> copy/paste the odd language into google and do a search...it will give you an option in there for a translate and tell you what the language is it is translating from and to.
[11:16:56] <Lambda_Aurigae> morning Jartza
[11:17:12] <Lambda_Aurigae> http://hackaday.com/2015/10/02/the-square-inch-project-challenges-your-layout-skills/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[11:17:27] <Lambda_Aurigae> something you might be interested in with your tiny-vga thingie.
[11:20:21] <Lambda_Aurigae> fit it on a 1 inch square board.
[11:23:04] <Lambda_Aurigae> Jartza, I think you would be a contender.
[11:23:26] <Lambda_Aurigae> specially if you could fit the color verson on the board.
[11:24:45] <Jartza> Lambda_Aurigae: oh
[11:24:47] <Jartza> guess what
[11:24:53] <Lambda_Aurigae> got the blog done?
[11:24:59] <Jartza> http://gerblook.org/pcb/WrfZBsCsuu3Nw2qZf9sRtL
[11:25:02] <Jartza> it's under construction :D
[11:25:12] <Lambda_Aurigae> nifty.
[11:25:17] <Lambda_Aurigae> how big is it?
[11:25:26] <Jartza> 1" x 1"
[11:25:27] <Jartza> :)
[11:25:31] <Lambda_Aurigae> sweet.
[11:25:43] <Jartza> and yes, indeed for that hackaday square inch contest
[11:25:46] <Lambda_Aurigae> get one built and functioning and get it submitted.
[11:25:51] <Jartza> yep
[11:26:01] <Lambda_Aurigae> I think it could win.
[11:26:03] <Jartza> just need to finish the traces and make silkscreen nicer looking
[11:29:51] <Jartza> it even has programming header on backside
[11:30:08] <Jartza> it needs one more jumper - called "slave programming"
[11:30:40] <Jartza> the master needs to be pulled to reset-state while programming slaves, as it will otherwise mess with the programming
[11:30:41] <Lambda_Aurigae> yeah..saw those programming pads.
[11:31:33] <Jartza> yeah. few traces still missing but there shouldn't be too much trouble routing them
[11:32:32] <Lambda_Aurigae> ever consider stacking the chips?
[11:32:42] <Lambda_Aurigae> I know you did stacked boards once.
[11:33:09] <Lambda_Aurigae> back in the day of 1Kx1bit srams we would stack them 8 tall then pull out the chip select lines and solder all the others together.
[11:33:25] <Lambda_Aurigae> to give 8K in one socket.
[11:33:39] <Jartza> yeah :D
[11:33:55] <Jartza> I thought about that with DIP versions
[11:34:01] <Lambda_Aurigae> think I'll try it.
[11:34:47] <Jartza> should work just fine
[11:39:08] <Lambda_Aurigae> yanno what else would be awesome.
[11:39:17] <Lambda_Aurigae> a vga credit card.
[11:40:00] <Lambda_Aurigae> sub-surface mount the chips though rather than surface mount like most people do on their credit card circuit boards.
[11:40:36] <Lambda_Aurigae> cut hole in the board that the chip sits down in and the pins come up and rest on the surface...have to bend them a little to fit but it works.
[11:41:16] <Lambda_Aurigae> I've done it with tqfp64 chips...bend the even pins then set the chip in the hole and rebend the even pins so they touch the back side of the board.
[11:42:28] <Lambda_Aurigae> half the pins on top, half on bottom.
[11:43:42] <learath> Lambda_Aurigae: fancy
[11:44:18] <Lambda_Aurigae> more like, I couldn't make the traces small enough with the gear I had at the time.
[11:44:24] <Lambda_Aurigae> but I could do a double sided board.
[11:52:16] <Lambda_Aurigae> with the smaller sot chips these days one could set them in a board and make them almost flush.
[12:01:12] <Jartza> sounds quite fancy yeah :)
[12:02:29] <Lambda_Aurigae> was atmega128 chips we were making badges out of.
[13:44:08] <Bushman> good UGT morning
[13:45:37] <Bushman> guys i want to make an if() statement based on EIFR's INTF0 flag. how can i read it directly from the if() statement?
[13:47:08] <Bushman> will this work? if(EIFR & INTF0){ foo(); }
[13:51:51] <aandrew> Bushman: yes and no
[13:52:14] <aandrew> I strongly suggest in the ISR doing uint8_t eifr = EIFR; then if (eifr & INTF0) { foo(); }
[13:52:16] <Bushman> fair enought.
[13:52:18] <Bushman> can you elaborate?
[13:52:35] <aandrew> so you have exactly one read (since most of those bits are clear-on-read)
[13:53:05] <Bushman> good tip. i should remember that. to bad i will forget anyway.
[13:54:02] <Bushman> also, the if is checked to handle the interrupt in the main loop.
[13:54:39] <Bushman> ....
[13:54:39] <Bushman> oh... um...
[13:55:16] <Bushman> i think this could run me into some problems
[13:55:53] <Bushman> aandrew: so if i read it in one IF, the next one will always fail intill next interrupt?
[13:56:15] <aandrew> correct, because you've read it and ALL the bits got cleared on that read
[13:56:20] <aandrew> it won't fail, you just won't see it
[13:57:34] <aandrew> perhaps if you explain more about what you're after
[13:57:46] <Bushman> no no, the next IF in the queue will always see 0, since the flag is cleared by the previous IF, right?
[13:58:05] <Bushman> ok, i use two external INT
[13:58:49] <Bushman> the vector handlers just read a free runing counter and save it to global variable and exit
[13:59:00] <Lambda_Aurigae> your & there,,,are you trying to do a bitwise & of the two?
[13:59:12] <Lambda_Aurigae> or are you saying if this AND that are both true then ??
[13:59:19] <Bushman> then in main loop i take those values and process them separately for each interrupt
[14:00:20] <Bushman> Lambda_Aurigae: in pseudocode: IF(interrupt0_flag){ foo();}
[14:00:49] <Bushman> but since this clears the whole register, i can't do that in this if.
[14:01:04] <Bushman> because in the next one i need to check the OTHER flag
[14:02:11] <aandrew> either use one interrupt handler for both or have both read into a common volatile mirror
[14:02:14] <aandrew> I'd do the former
[14:04:15] <Bushman> i can't have the same handler, i need to distinguish them
[14:05:27] <Bushman> at least i'm not good at C to do that yet
[14:05:39] <Bushman> *not good enough
[14:09:37] <aandrew> Bushman: not at all
[14:09:43] <aandrew> one moment let me give you an example
[14:12:04] <Bushman> well, i have two inputs, they go up down independently. i need to get time betwin going high and low separately for each.
[14:15:41] <aandrew> Bushman:
https://gist.github.com/akohlsmith/51ae0b7f6fb7a62e115b
[14:16:22] <aandrew> the cli/set_false/sei can be replaced if you have a guaranteed atomic way to set the value false, and it's not at all needed if you don't care if you miss an event
[14:17:02] <aandrew> Bushman: I did that exact thing with an AVR for my prox card reader code
[14:17:49] <aandrew> Bushman: basically you route the vectors to the same function, and that function does the dirty work
[14:18:07] <aandrew> it's only necessary if you have to determine what to do and you can only read the interrupt source once
[14:18:20] <aandrew> if you don't ahve to, then there's no real advantage of doing it this way
[14:18:49] <Lambda_Aurigae> just remember to keep things inside interrupt routines short and sweet....update volatile variables and get out....
[14:18:58] <aandrew> yep
[14:30:49] <Bushman> ok, i need to digest that.
[14:36:03] <Bushman> aandrew: does disabling the interrupts for a moment can miss any rising or falling edge on INT0/1 input?
[14:36:05] <Bushman> hmm...
[14:36:32] <Lambda_Aurigae> if you get more than one, yes.
[14:43:03] <Bushman> so technically cli, falling edge, sei, will result in the interrupt vector being executed anyway?
[14:43:18] <aandrew> no
[14:43:21] <aandrew> it delays them
[14:43:43] <aandrew> cli still lets the flag get set. you just don't get the interrupt until sei is executed
[14:43:43] <Lambda_Aurigae> I think it should trigger after the sei..
[14:43:59] <aandrew> cli prevents an interrupt from occuring, ti doesn't prevent one from getting flagged
[14:44:02] <Bushman> cool
[14:44:31] <aandrew> which is also why you don't use cli/sei to do anything requiring time because you can cause long delays
[14:44:34] <Bushman> that's cool. then your example is very good ;]
[14:45:37] <aandrew> I honestly don't think you need cli/sei around the setting of the flag to false because IIRC it just gets coded as a bsc or whatever the instruction is
[14:45:45] <aandrew> and all instructions are atomic on avr
[14:46:04] <Bushman> hmm...
[14:46:18] <Lambda_Aurigae> make sure any variable changed inside an interrupt is declared volatile.
[16:33:59] <Bushman> ok, i'm clearly failing at bit operations so can someone help me understand what i'm doing wrong?
[16:34:32] <Bushman> there is register EIFR with bits INTF0 and INTF1
[16:34:50] <Bushman> i want to read those bits and store them in my variable
[16:35:11] <Lambda_Aurigae> variable = EIFR & INTF0;
[16:36:01] <Bushman> hmm...
[16:36:16] <Lambda_Aurigae> variable = EIFR & (INTF0 | INTF1)
[16:36:23] <Lambda_Aurigae> gets both bits.
[16:36:47] <Bushman> or simply var = EIFR for both?
[16:37:01] <Lambda_Aurigae> that gets other things as well if there are other bits in the register.
[16:37:12] <Bushman> no, just those two
[16:37:19] <Bushman> other should read as 0
[16:37:30] <Lambda_Aurigae> ok, then, what's the problem?
[16:37:38] <Bushman> ok. but now, reading this register clears those bits, right?
[16:37:50] <Lambda_Aurigae> dunno..what does the datasheet say?
[16:38:09] <Bushman> not sure.
[16:38:39] <Lambda_Aurigae> what chip?
[16:38:42] <Bushman> When an edge or logic change on the INT0 pin triggers an interrupt request, INTF0 becomes set (one). If the I-
[16:38:42] <Bushman> bit in SREG and the INT0 bit in EIMSK are set (one), the MCU will jump to the corresponding Interrupt Vector.
[16:38:45] <Bushman> The flag is cleared when the interrupt routine is executed. Alternatively, the flag can be cleared by writing a
[16:38:48] <Bushman> logical one to it.
[16:38:50] <Bushman> 328p
[16:39:14] <Bushman> "the flag is cleared when the interrupt routine is executed"
[16:39:16] <Lambda_Aurigae> so, the flag is cleared when the interrupt routine is executed...you won't be able to read it.
[16:39:37] <Bushman> does that mean i can not read it inside the interrupt cause it's already cleared?
[16:39:43] <Lambda_Aurigae> bingo.
[16:39:47] <Lambda_Aurigae> just exactly what it says.
[16:40:21] <Bushman> ok
[16:40:23] <Bushman> then i'll have to resort to manually setting those bits in my variable
[16:40:33] <Bushman> so now again, can i use bit name to set it in my variable?
[16:40:41] <Lambda_Aurigae> if that interrupt gets called then that bit was set to 1.
[16:40:48] <Lambda_Aurigae> sure.
[16:40:54] <Lambda_Aurigae> or just set the variable to 1.
[16:41:06] <Bushman> like register is EIFR and my variable is lowercase eifr
[16:41:08] <Lambda_Aurigae> unless you are using one variable to hold multiple things.
[16:41:33] <Bushman> and i want to set the bit with INTF0 as "value"
[16:42:13] <Bushman> so: eifr |= (1<<INTF0);
[16:42:15] <Lambda_Aurigae> variable = variable | INTF0;
[16:42:17] <Bushman> should work?
[16:42:24] <Bushman> or that
[16:42:26] <Lambda_Aurigae> oh, wait,,,depends on what INTF0 is actually set to.
[16:42:32] <Lambda_Aurigae> probably yours.
[16:42:48] <Lambda_Aurigae> I tend to use hex or binary numbers...they make more sense to me.
[16:43:08] <Bushman> well, if it's 0, it should be 1, if it's 1, it still should be 1
[16:43:35] <Bushman> so boolean OR
[16:43:36] <Bushman> yes?
[16:43:55] <Lambda_Aurigae> what I mean is,,,is INTF0 set as a number 0 to 7 or as the actual bit value of the register bit such as 0b00010000
[16:44:09] <Lambda_Aurigae> I think it is 0 to 7 which means yours works.
[16:48:00] <Roklobsta> If anyone is interested i am selling my AVR Raven kit. PM me for details.
[16:48:30] <Bushman> ok, i think i've corrected it now.
[16:50:45] <Bushman> i no longer try to read the register, i just write coresponding bit to my variable, perform the time-critical operations and then handle the rest in main loop ONLY when the interrupt bit in my variable is set
[16:51:05] <Bushman> that should off-load the main loop :P
[16:52:19] <Bushman> so far it was doing everything regardles if the interrupt happened or not, effectively coming up with the same results god only knows how many times in a row.
[17:55:01] <Bushman> Lambda_Aurigae: aandrew: i've finished the hard part!
[17:55:03] <Bushman> https://www.youtube.com/watch?v=R92nimRJldo
[17:55:04] <Bushman> ;]
[18:02:50] <Jartza> hmmh. 2 more airwires to go
[18:12:32] <Jartza> ohh
[18:13:11] <Lambda_Aurigae> hurt yourself?
[18:25:08] <Jartza> Lambda_Aurigae: nope :)
[18:25:25] <Jartza> Lambda_Aurigae: got this routed:
http://gerblook.org/pcb/6zfdoV7dNmfgWPaq2MgHVA
[18:26:27] <Lambda_Aurigae> kewl.
[18:26:32] <Lambda_Aurigae> now to make one.
[18:26:52] <Jartza> yeah
[19:05:28] <Jartza> well
[19:05:29] <Jartza> http://gerblook.org/pcb/z9ykdP8wuoedBzVk3n2Aei
[19:05:31] <Jartza> fixed a bit
[21:48:23] <rue_school> Bushman, good show! C or arduino?
[21:49:07] <theBear> am not a bushman ! i'm just not overly fancy :-)
[21:55:15] <apo__> Jartza: What's that going to be?
[22:01:23] <Bushman> rue_school: C
[22:03:31] <Bushman> rue_school: some guy did the same thing with arduino as he claims with 4 lines of code.
[22:03:44] <Bushman> the problem is he didn't post the code. :D
[22:04:16] <Bushman> other people doing this on arduino were told their aproach has some inherrent flaws...
[22:04:38] <Bushman> so i've decided to do it the hard way and write my own code in C
[22:36:34] <apo__> C ♥
[22:38:14] <apo__> Bushman: I'll write a library to do the thing, then include that library and do it in one line of code
[22:38:31] <apo__> that's how linecounts work, right
[23:24:40] <gorroth> C is so great
[23:24:55] <gorroth> i like C++ too, but for working on the AVR, i tend to gravitate just towards C
[23:25:24] <gorroth> even my small PC apps that connect to the AVR over UART are currently C, but i'm thinking of rewriting one of them in C++ soon
[23:26:11] <gorroth> oh, this is in reference to the earlier talk about C vs arduino
[23:26:27] <gorroth> https://github.com/grimwm/avr if you want some nice code for working with AVrs
[23:26:30] <gorroth> AVRs
[23:26:34] <gorroth> especially from the RPi
[23:27:06] <gorroth> it's in flux, and some things are a bit broken on the "master" programs on the master branch, but i'm starting to get it cleaned up on the serial branch and will be merging to master soon
[23:27:22] <gorroth> all under the MPLv2
[23:27:42] <gorroth> the "serial" branch has early joystick code too