#avr | Logs for 2014-05-04

Back
[00:45:46] <dgriffi> a week or so ago, someone showed me some code for reading a 4x4 keypad. Who was that?
[02:28:39] <Fleck> dgriffi: [02:57:52] <Lambda_Aurigae> simple 4x4 is easy...reading multiple keys is more difficult and requires diodes in the circuit I do believe.
[02:29:04] <dgriffi> Fleck: I've cured myself of trying to do multiple keys
[02:29:32] <dgriffi> Fleck: I want to be able to use an off-the-shelf keypad and those typically don't have diodes
[02:30:19] <dgriffi> anyhow, I'm fooling around with Lambda's code and I can't detect 4th column
[02:31:39] <dgriffi> going to try something else
[02:33:25] <Fleck> !log
[02:33:46] <Fleck> no more channel logging Tom_itx?
[02:34:48] <dgriffi> Here's what I'm doing: http://pastebin.com/6TPP35H2
[02:35:59] <dgriffi> unfortunately I don't have all the parts to hook up an LCD, so I have four LEDs displaying four bits
[02:36:30] <dgriffi> fortunately I haven't fried anything yet... I think...
[02:36:35] <Fleck> dgriffi: http://tom-itx.dyndns.org:81/~tom-itx/irc/logs/%23avr/index.html
[02:37:04] <dgriffi> oh dear lord
[03:59:48] <dgriffi> I'm getting sick of this. I keep trying various examples and I can't get any 4x4 keypad-reading code to work
[04:01:56] <dgriffi> does anyone have any 4x4 code that actually works?
[04:05:18] <Thrashbarg> dgriffi: looking at that code, you need to set KEYPAD_DDR = 0x0F in initkeypad() so it reads four pins instead of three
[04:07:26] <Thrashbarg> and KEYPAD_PORT = 0x06, 0x05, 0x03, 0x01 to 0x0E, 0x0D, 0x0B, 0x07
[04:08:34] <Thrashbarg> and KEYPAD_PIN | 0x07 to 0x0F
[04:08:45] <dgriffi> okay.. pulling up that one...
[04:10:07] <dgriffi> I wish I knew what was going on there
[04:10:25] <Thrashbarg> it's setting the low four bits of the port to outputs and the upper four to inputs
[04:10:44] <Thrashbarg> then it scans the lower four bits one by one until it detects a low on the upper four bits
[04:11:00] <dgriffi> okay, I tried this and the far-right column isn't being detected
[04:12:42] <dgriffi> still stumped
[04:12:58] <Thrashbarg> change 0xF8 on the KEYPAD_PORT lines to 0xF0
[04:13:22] <Thrashbarg> it'd be simpler if it were done slightly differently, hang on a sec
[04:13:29] <dgriffi> yes please
[04:14:42] <dgriffi> now the fourth column is being detected, but I'm getting nonsense from getkey()
[04:14:50] <Thrashbarg> yeah
[04:15:17] <dgriffi> I'm hoping to get an integer from 0 to 16 with 0 if nothing is pressed
[04:15:24] <Thrashbarg> ok
[04:15:32] <Thrashbarg> well you won't get that from this code
[04:16:18] <Thrashbarg> http://pastebin.com/GhKLS1Ji
[04:16:22] <Thrashbarg> see what that doesn't
[04:17:58] <dgriffi> okay... what is getkey() supposed to return in your code?
[04:18:11] <Thrashbarg> in that it'll return the column that was pressed only
[04:18:16] <Thrashbarg> but from any row
[04:18:32] <Thrashbarg> does it do that?
[04:18:59] <dgriffi> I get unique values for each column
[04:19:07] <Thrashbarg> ok
[04:19:21] <rue_bed> matrix keyboard?
[04:19:25] <dgriffi> yes
[04:19:29] <dgriffi> 4x4 matrix
[04:19:30] <Thrashbarg> so the row is on one nibble and the column is on the other?
[04:19:36] <dgriffi> yes
[04:19:37] <rue_bed> nobody liked hte code I posted?
[04:19:46] <rue_bed> sounds like mine
[04:20:09] <rue_bed> and you get an arbitrary unique number back
[04:20:24] <rue_bed> for each key, use a lookup table to translate to something else
[04:20:41] <Thrashbarg> I changed it a little to work with a 4x4 keypad... seems it was only for a 3x4 keypad
[04:21:32] <rue_bed> ah good show
[04:21:45] <Thrashbarg> changed the code to make it a little clearer too
[04:22:02] <Thrashbarg> KEYPAD_PORT = ~(1<<2); etc
[04:22:22] <rue_bed> indeed
[04:22:30] <dgriffi> I'm still mystified
[04:22:48] <Thrashbarg> dgriffi: ypu
[04:22:50] <Thrashbarg> oops
[04:22:59] <Thrashbarg> you're getting unique codes for each key?
[04:23:34] <dgriffi> let me show you some other code.. maybe you can help me with that one
[04:23:38] <Thrashbarg> ok
[04:25:11] <rue_bed> each key always gives the same 8 bit code
[04:25:23] <rue_bed> its the raw scan information
[04:25:27] <Thrashbarg> yea individually
[04:25:32] <dgriffi> not sure.. I only have five LEDs on the breadboard
[04:25:36] <Thrashbarg> heh
[04:25:56] <rue_bed> but its not just like 0-15, you get numbers that are effectivly random
[04:28:04] <Thrashbarg> using an 8-bit lookup table would be wasteful really
[04:28:14] <Thrashbarg> you'd need 256 values which only have 16 used
[04:43:20] <Thrashbarg> dgriffi: http://pastebin.com/tYbd66iq <--- not sure if that'll work but give it a go
[04:49:17] <dgriffi> as-is, no... but I inverted the output of getkey() and it works
[04:49:46] <dgriffi> err.. wait a minute
[04:50:15] <dgriffi> getkey DOES return the correct value... I just need to invert that to get the LEDs to light up correctly
[04:50:22] <dgriffi> am I right?
[04:52:01] <Thrashbarg> is this for my code or the original?
[04:52:27] <dgriffi> for your code that you just pastbinned
[04:52:59] <Thrashbarg> ok so are the LED's all on when there's no keypress?
[04:53:05] <dgriffi> yes
[04:53:17] <Thrashbarg> so they're wired from +5V to the AVR?
[04:53:36] <dgriffi> yes
[04:53:54] <Thrashbarg> yup ok stick a ~ before getkey() in the main loop
[04:54:04] <dgriffi> +5V -> LED -> 220ohms -> AVR
[04:55:17] <dgriffi> I noticed earlier that if I want to display binary 2, I needed to do this: PORTC = ~2;
[04:56:06] <Thrashbarg> yea it's because the LED illuminates when the output pin is low
[04:56:12] <Thrashbarg> i.e. connected to ground
[04:56:21] <Thrashbarg> so 5V -> LED -> resistor -> ground lights it
[04:56:31] <Thrashbarg> but 5V -> LED -> resistor -> 5V doesn't light it
[04:56:36] <dgriffi> right
[05:00:43] <dgriffi> ah.. I understand now
[05:03:41] <dgriffi> now that that's done... how do I go about debouncing?
[05:04:48] <Thrashbarg> I've not had to do debouncing in software myself... you can look it up yourself right?
[05:05:38] <OndraSter> even simple parallel cap helps a lot with debouncing
[05:06:18] <Thrashbarg> yup
[05:09:17] <dgriffi> hmm... so, if I delay, say, 25ms after "d = KEYPAD_PIN;", that should do it?
[05:09:40] <dgriffi> err... no
[05:16:01] <dgriffi> OndraSter: with the keypad I'm using, I can't put a cap right next to the key
[05:16:11] <OndraSter> ah
[05:22:18] <dgriffi> how does this look for software debouncing? http://pastebin.com/x12sx1Pb
[05:30:07] <dgriffi> Thrashbarg: Thanks
[05:59:07] <Thrashbarg> dgriffi: shouldn't that be if (d != 0xFF) instead of 0x00?
[05:59:25] <Thrashbarg> it's never going to be 0x00 so the if will always execute
[06:02:20] <dgriffi> actually it works
[06:02:58] <dgriffi> I turned the delay period up to five seconds and it would wait for the button to be held down for five seconds before turning on LEDs
[06:03:35] <Thrashbarg> yea because it's always executing that if statement
[06:06:20] <dgriffi> Thrashbarg: shouldn't KEYPAD_PIN be 0x00 if nothing is being pressed?
[06:06:52] <Thrashbarg> no it'd be 0xFF because of pullup resistors
[06:07:40] <Thrashbarg> it should be if ((d | 0x0F) != 0xFF) {
[06:08:03] <Thrashbarg> because you want to set the low four bits to 1's because one will be low
[06:08:06] <Thrashbarg> for the scanning
[06:09:04] <dgriffi> now I get no output
[06:09:16] <Thrashbarg> :/
[06:09:45] <Thrashbarg> set debounce time to a few milliseconds?
[06:09:53] <dgriffi> yep
[06:11:02] <dgriffi> what I'm trying to do is "1) has any key been pressed? If so, wait 20 ms and then read which key was pressed."
[06:14:24] <Thrashbarg> you could use the same code but put a delay before it returns with the data. That'd work on any button being pressed causes it to trigger, but it waits long enough for any contact bounce to settle before trying again
[06:15:17] <dgriffi> ugh... right
[06:15:22] <Thrashbarg> you'd do that by moving the_delay_ms line to the if statement with the return statement in it, before the return statement
[06:15:29] <Thrashbarg> and delete the if statement you added
[06:15:34] <dgriffi> that would be simpler
[06:22:35] <dgriffi> err... that appeared to amplify boucing
[06:23:17] <Thrashbarg> perhaps the bouncing is there for longer than the delay?
[06:29:12] <dgriffi> Thrashbarg: no... when the rightmost column is pressed (simulated with two jumpers) the correct LED lights up, but it flickers
[06:29:34] <Thrashbarg> :/
[06:29:35] <Thrashbarg> weird
[06:30:54] <dgriffi> http://pastebin.com/DGumNXt7
[06:31:52] <Thrashbarg> so you're monitoring the debounce on portb
[06:32:00] <dgriffi> yes
[06:32:16] <Thrashbarg> it'll appear to be on because there's no delay after it's set to 0
[06:32:51] <Thrashbarg> wait you're connecting the LEDs to 5V
[06:33:03] <dgriffi> I wrote that because I was interested mainly in knowing when the debounce is started
[06:33:08] <dgriffi> no, I switched the LEDs around
[06:33:11] <Thrashbarg> ok
[06:33:24] <Thrashbarg> put another delay after PORTB = 0x00
[06:33:32] <Thrashbarg> and half the delay
[06:34:00] <Thrashbarg> you can put the code in the first if statement into the start of the second one btw
[06:34:05] <Thrashbarg> and delete the first one
[06:34:43] <dgriffi> I know, but when I tried that, weird things started happening
[06:34:55] <Thrashbarg> do you have code optimisation set?
[06:35:05] <dgriffi> I don't know
[06:35:16] <Thrashbarg> that is, are you compiling with -O2 -O3 or something like that set?
[06:35:24] <Thrashbarg> I've always had grief with those
[06:36:18] <dgriffi> ick... that went from 240 bytes to 3614 bytes
[06:36:27] <Thrashbarg> heh
[06:40:02] <dgriffi> Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" [-Wcpp]
[06:40:12] <Thrashbarg> lol
[06:40:33] <Thrashbarg> hmm
[06:40:38] <Thrashbarg> ok scratch that
[06:43:49] <dgriffi> If I do "if ((d | 0xFF) != 0xFF) {" for the seperate debouncing if, things seem to work okay
[06:44:42] <dgriffi> ugh... that's wrong
[06:46:56] <Thrashbarg> ah so it never executes the debounce code
[06:47:00] <Thrashbarg> in that case
[06:50:46] <dgriffi> Here's what I have now. the debounce runs, but 0x00 is always returned from getkey()
[06:50:54] <dgriffi> http://pastebin.com/MMNbAS0h
[06:51:39] <Thrashbarg> how long are you holding the key down for/
[06:51:40] <Thrashbarg> ?
[06:51:51] <dgriffi> a few seconds
[06:53:08] <Thrashbarg> ah it'd help too to put a slight delay (20ms) between KEYPAD_PORT and d = KEYPAD_PIN
[06:53:34] <Thrashbarg> because it'd take a tiny bit of time for the voltage to change from the output of the port and come back to the input
[06:53:46] <Thrashbarg> "settling time"
[06:54:15] <dgriffi> ah.. I switched back to the 4th column flickering problem code and added that delay.. that fixed the flicker
[06:54:30] <Thrashbarg> good
[06:55:50] <dgriffi> now, cranking back the debounce time to something realistic...
[06:56:25] <dgriffi> good so far...
[06:56:46] <dgriffi> now trying to consolidate the two ifs into one like you suggested earlier
[07:00:08] <superware> is the following "efficient" if i2c_readAck return an unsigned char? int32_t* count; ... *count = i2c_readAck() | ((s32)i2c_readAck()<<8) | ((s32)i2c_readAck()<<16);
[07:02:51] <dgriffi> Thrashbarg: Doing this: http://pastebin.com/a4S5QGdm, about half the time the LEDs that were not lit will flash when the button is released
[07:03:11] <dgriffi> Thrashbarg: If I use the seperate if statement, this doesn't happen
[07:04:31] <Thrashbarg> dgriffi: I doubt you need the second delay and sample, because the delay between setting the output and sampling the port should be plenty of time for it to settle. It's a bit of a blind debounce
[07:05:47] <dgriffi> so you're saying I should remove the debouncing alltogether?
[07:06:59] <Thrashbarg> no I'm saying if you let it settle for long enough between changing the output to reading the input, it should have settled
[07:07:24] <Thrashbarg> the switch bounce only lasts for a few milliseconds, assuming the contacts on the switch are good
[07:07:31] <dgriffi> I'm fuzzy on what you mean.. could you pastbin it?
[07:09:06] <Thrashbarg> http://pastebin.com/8htxQ7QU
[07:10:00] <dgriffi> I don't get it...
[07:21:39] <dgriffi> Thrashbarg: thanks for your help. I'll sleep on this and try again later.
[07:23:18] <Thrashbarg> k
[09:02:37] <Lambda_Aurigae> May the Fourth be with you
[09:02:55] <Thrashbarg> quiet you!
[09:06:07] <Lambda_Aurigae> careful or I'll forth choke you!
[09:32:16] <Tom_itx> SPI class is now in session
[09:35:47] <Lambda_Aurigae> I prefer i2c myself.
[09:36:05] <timemage> Tom_itx, you're teaching a class?
[09:36:56] <Tom_itx> no but it seems some UNI is teaching SPI
[09:37:05] <Tom_itx> 2 have come for the same help
[09:37:33] <timemage> Tom_itx, ah, i see. i missed the above.
[09:37:53] <Tom_itx> Pi to avr
[12:30:04] <Fleck> hey, I got this sensor: http://digipak.org/zencart/images/ACS712.jpg << now, the q. - as you know - at 0A output stays at 2.5V (for ideal 5V supply), so I only get half of 10-bit resolution for 0A to 30A, I don't need -30A, can I use OP-AMP to increase resolution? like, make a circuit so that 2.5V at OP-AMPs output is 0V and 5V is 5V, will that increase my ADC resolution?
[12:30:37] <Fleck> meh, hope you can understand that :P sorry for my english!
[12:35:42] <Fleck> I think q. for Thrashbarg and tzanger! :D
[12:36:29] <Fleck> and not for The_Coolest! :D
[12:36:40] <The_Coolest> ?
[12:37:01] <Thrashbarg> Fleck: and 5V is 5V? eh?
[12:37:22] <Thrashbarg> ah I see
[12:37:23] <Fleck> well yes, 5V for sensor out is 5V op-amps out also
[12:37:34] <Fleck> The_Coolest: just joking, nevermind! :)
[12:38:06] <The_Coolest> Fleck what would the op amp do?
[12:38:37] <Fleck> extend range... from 2.5V-5V to 0V-5V for ADC
[12:38:42] <The_Coolest> if you only want to monitor forward current, you probably can
[12:39:27] <Fleck> yep, as said - I don't need to measure 0A to -30A
[12:40:24] <The_Coolest> you would need an opamp with true rail to rail capability, or run it at higher voltage than 5v
[12:40:36] <Fleck> have such opamps
[12:40:51] <The_Coolest> well then it shouldn't be too hard
[12:41:17] <Fleck> it's not hard, the q. is - will that increase my resolution to full 10-bit res, not half
[12:41:35] <Fleck> as far as I understad - it will, but...
[12:41:52] <The_Coolest> if youo use inverted mode, you give the +VIN 2.5v reference, then setup a x2 gain feedback loop
[12:41:58] <The_Coolest> and that's about it
[12:42:33] <The_Coolest> it'll increase it, not double it though if your op amps VCC is the same as that sensor
[12:43:24] <Fleck> I have 10V supply there
[12:43:27] <The_Coolest> rail to rail op amps can't really output voltages the same as the vcc (usually)
[12:43:32] <The_Coolest> ah ok then
[12:43:59] <The_Coolest> then you should get the 'full' resolution
[12:44:53] <Fleck> cool!
[13:01:18] <rue_bed> they just get closer than anything else
[13:01:27] <rue_bed> usually by about .045V
[13:16:50] <The_Coolest> who?
[13:17:00] <The_Coolest> oh yes
[14:10:25] <Brittany> I have my atmega 644p set up as SPI slave, and raspberry pi as master. I've verified the wiring is correct, the clock signal at the raspberry pi is 1MHz for SPI. I have them talking, with the standard examples given for transmit and receive of simple characters. The raspberry pi opens the SPI Port, then does http://pastie.org/9140166 where the aim is to take characters from the 'arr' array, send them over to the AVR, and then have this pasted
[14:10:26] <Brittany> into 'pass' array as a simple test. The code at the AVR side http://pastie.org/9140159 does that. My problem is a bit cryptic to me because I'm a beginner with any communications protocol. Sometimes I get my fall passphrase, and sometimes I get absolutely nothing. Can someone suggest to me why this might be an issue?
[14:12:15] <Brittany> For the record, I've tried multiple clock speeds at master, but the problem is reproduced each time.
[14:30:08] <Brittany> Just tried to add a delay in to the avr end. It didn't yield any difference.
[14:30:26] <Brittany> (Putting delays of 10 microseconds after each transmit or receive
[14:45:20] <Brittany> Just made some adjustments. I'm still looking for some information if possible. I changed the way to detect what was coming back by printing out all elements of the array of bytes as opposed to just doing cout << array;
[14:45:38] <Brittany> and now all I'm getting is discrepencies per each iteration of the program.
[14:46:01] <Brittany> I send helloworld, I get helworld, helloworld, helloworld, heoworld, helloworl.
[15:37:11] <tzanger> Brittany: just from your description it looks like you're taking too long to receive characters and are sometimes missing them
[15:38:20] <tzanger> what is your SPI clock speed, and those look like fairly high level functions, is this Arduino code?
[15:44:16] <Casper> rue_more: for wiring in conduit outside, that ain't burried, do you need it to be nmwu or standard interior one is allowed? (basically 10ft on the wall)
[15:44:41] <Casper> I think standard is allowed, but just want to be sure if I need to replace the existing wire or if I can reuse/relocate it
[16:46:40] <Brittany> tzanger: SPI Clock Speed is 1MHz right now it's not for arduino, it's for Raspberry Pi communicating with Atmega 644P. On one side, standard C++, on the other, AVR-C
[16:50:43] <tzanger> no I understand that, but what code is running on the 644P
[16:50:49] <tzanger> the code snippet you pasted looks pretty high level
[16:51:04] <Lambda_Aurigae> yeah..you haven't shown any of the actual spi code.
[16:59:04] <Tom_itx> Brittany, are you using SPI interrupts?
[17:00:24] <Tom_itx> seems you are doing the same UNI project as pickletown who isn't here atm
[17:00:48] <johnwalkr> raspberry pi has a hardware bug for i2c
[17:00:54] <johnwalkr> it doesn’t do clock stretching properly
[17:01:00] <Tom_itx> this isn't i2c
[17:01:03] <Tom_itx> it's SPI
[17:01:15] <johnwalkr> oh, so it is. not sure how i read that as i2c
[17:01:16] <johnwalkr> sorry
[17:01:35] <Tom_itx> maybe a similar bug though?
[17:01:37] <Tom_itx> who knows
[17:09:44] <Brittany> Tom_itx
[17:09:52] <Brittany> I'm not using interrupts, I'd like to but I'm not all too sure how.
[17:11:01] <Brittany> tzanger the functions SPIReceive and SPITransmit are just SPDR=data; while(!(SPSR&(1<<SPIF)));
[17:11:10] <Brittany> and while(!(SPSR&(1<<SPIF))); return SPDR;
[17:16:09] <Fleck> The_Coolest: http://im9.eu/picture/w324731
[17:16:43] <tzanger> Brittany: ok so basically you're forcing the system to receive 256 bytes
[17:16:55] <tzanger> can you verify what you receive in the atmega?
[17:17:54] <Casper> hmmmm do I waste tons of ressources with that led fader? and use float?
[17:18:03] <tzanger> Casper: of course not
[17:18:05] <Casper> or just use integers....
[17:18:17] <tzanger> you use fixed point arithmetic if you REALLY feel you need to have fractions
[17:18:27] <Casper> the code will be tiny
[17:18:36] <Casper> so I have tons of ressources to spare
[17:18:40] <tzanger> why waste them?
[17:18:45] <tzanger> I mean don't optimize
[17:18:51] <Casper> because it will be even more wasted if I don't :D
[17:18:52] <tzanger> but don't waste them just for the sake of waste
[17:20:13] <tzanger> a basic LED fader in a 100us interrupt: unsigned char ticks; ++ticks; if (fadepoint > ticks) led=1; else led=0;
[17:20:20] <Casper> the code will be basically to set 3 PWM output, then set all at 100% 0% 0%, then loop to increase it gradually to 100% 100% 0%, then to 0% 100% 0% and so on
[17:20:21] <tzanger> no floats needed
[17:20:25] <Casper> with a delay between each change
[17:20:38] <Casper> so will waste time in delay loop..
[17:20:52] <tzanger> update fadepoint every 25ms or something. that's very (stupid) simple software PWM for one channel
[17:21:05] <Casper> or I use float and I use a function that calculate the change per tick...
[17:21:06] <Casper> :D
[17:21:23] <tzanger> however you like. floats are really frowned upon 'round here
[17:21:28] <tzanger> totally wasteful for zero gain
[17:21:29] <Casper> I know
[17:21:32] <Casper> yup
[17:21:43] <Fleck> tzanger: can you check that circuit, is it right? (I need to convert 2.5V to 5V interval to 0V to 5V output interval)
[17:21:45] <Kev> Brittany a logic analyzer might help
[17:21:46] <Casper> but... I'll use at atmega88pa for that....
[17:21:46] <tzanger> it doesn't get you increased readability or portability. it doesn't get you increased speed or features
[17:21:49] <Kev> if you have one
[17:21:55] <Casper> imagine all the wasted ressources there!!! :D
[17:22:11] <Brittany> Tzanger: any suggestions to verify?
[17:22:12] <tzanger> Casper: spend the extra hour and learn a valuable skill
[17:22:15] <tzanger> that's NEVER wasted time
[17:22:21] <tzanger> Brittany: set a breakpoint and read the array
[17:22:28] <tzanger> Fleck: which circuit
[17:22:34] <Fleck> http://im9.eu/picture/w324731
[17:22:49] <tzanger> why on earth are you using 1M resistors?
[17:22:53] <Fleck> :D
[17:23:05] <tzanger> that's almost as bad as using floating point
[17:23:12] <Casper> hmmm those mp3 sound like a 128kbit upsampled to 320... grrr
[17:23:35] <Fleck> tzanger: http://im9.eu/picture/r324730
[17:24:33] <Casper> ow well, wills do it the good ol' way... hard code the few loops, and call a variable delay pause...
[17:25:01] <tzanger> Fleck: think about what you want to do
[17:25:12] <tzanger> you want to subtract off 2.5V and multiply by two
[17:25:21] <tzanger> you know the op amp circuits for both
[17:25:28] <Fleck> :)
[17:25:38] <Fleck> this seems to be working... but ok, Ill think more!
[17:26:13] <tzanger> well simulate it. give yourself a 2.5-5V sine wave and see if you get a 0-5V output sine
[17:26:13] <Lambda_Aurigae> careful with that.
[17:26:18] <Lambda_Aurigae> thinking can be painful.
[17:26:25] <tzanger> give yourself a 0-5V input and see what the output looks like
[17:26:36] <tzanger> it's like gym day. it's a good pain
[17:26:38] <Fleck> I did
[17:27:11] <Kev> Brittany hey also, did you wire the raspi's gnd with the atmega's gnd ?
[17:32:14] <tzanger> Fleck: so if it works what is the question?
[17:32:50] <tzanger> personally I don't think that circuit works
[17:34:08] <Fleck> http://im9.eu/picture/a324732
[17:34:44] <Fleck> I would love to give you a link but I can't copy it :P dunno why
[17:35:32] <Fleck> and input is not suposed to be 0V-5V, but 2.5V-5V
[17:35:37] <Fleck> output should be 0V-5V
[17:35:38] <Kev> Fleck what's that sim software you're using ?
[17:35:49] <Fleck> Kev: http://www.falstad.com/circuit/
[17:35:53] <Brittany> Kev: I've not wired pin 6 at GPIO with AVR's GND
[17:36:03] <Brittany> but I connected one of the DNC pins to AVR GND
[17:36:31] <tzanger> https://www.circuitlab.com/circuit/v7yy7h/sensor-range/
[17:36:33] <Lambda_Aurigae> DNC meaning,,,do not connect?
[17:36:35] <tzanger> doesn't seem to work to me
[17:36:57] <Kev> Fleck thanks
[17:37:12] <Fleck> tzanger: you have wrong offset/voltage for sine gen
[17:37:37] <Fleck> Vmax = 1.25V, Voff = 3.75V
[17:37:40] <tzanger> 2.5V offset and 2.5V amplitude?
[17:38:11] <tzanger> actually yeah the graph is showing the input is bonkers
[17:38:23] <Fleck> Input is in range: 2.5V to 5V
[17:38:44] <Fleck> output swings from 0V (when input is at 2.5V) to 5V (when input is at 5V)
[17:39:45] <tzanger> yeah it simulates fine now that I fixed the input :-)
[17:40:41] <Fleck> how would you do it tzanger?
[17:43:07] <tzanger> there's nothing wrong with what you've done
[17:43:46] <Fleck> ohh, ok, thank you! :)
[18:02:00] <Brittany> whoever suggested to ground it
[18:02:01] <Brittany> thank you
[18:02:03] <Brittany> fuck my goddamn life
[18:02:43] <Brittany> for some reasons some sites list DNC as GND.
[18:02:47] <Fleck> language Brittany!
[18:03:03] <Brittany> Sorry. Didn't know there was a rule for thast.
[18:03:14] <Tom_itx> we speak avr here
[18:03:25] <Fleck> :D
[18:03:28] <Tom_itx> that's not part of the avr assembly language
[18:04:19] <Brittany> Though I must say
[18:04:26] <Brittany> as a kid I used to spend a lot of time programming my atari
[18:04:41] <Brittany> I got in serious trouble with my mum when she saw the screen looping "WHY THE F*CK AREN'T YOU WORKING"
[18:04:50] <Brittany> and changing background colours randomly
[18:05:35] <Tom_itx> [02:33:46] <Fleck> no more channel logging Tom_itx?
[18:05:36] <Tom_itx> zlog
[18:05:58] <Fleck> Tom_itx: read more lines :D
[18:06:00] <Fleck> just few...
[18:06:05] <Tom_itx> oh
[18:06:54] <Fleck> :D I have no clue how I found that link though
[18:07:02] <Tom_itx> Brittany,
[18:07:14] <Tom_itx> [10:26:37] <Tom_itx> spi uses sck, mosi, miso
[18:07:15] <Tom_itx> [10:27:13] <Tom_itx> slow the pie down until you got it working
[18:07:15] <Tom_itx> [10:27:20] <Tom_itx> then ramp up the sck rate
[18:07:27] <Tom_itx> [10:28:44] <Tom_itx> start with a slower SCK rate unitl it's stable
[18:07:28] <Tom_itx> [10:28:59] <Tom_itx> make sure all the GNDs are good etc
[18:07:28] <Tom_itx> [10:29:07] <Tom_itx> noise affects things
[18:07:50] <Tom_itx> that was for your friend
[18:07:56] <Tom_itx> pickletown
[18:08:00] <Tom_itx> but the same applies to you
[18:08:38] <Tom_itx> now go share your code with him so he can get his working too
[18:08:56] <Fleck> ;p
[18:13:51] <Casper> ew.... man it's been so long since I got time to code that....
[18:14:00] <Casper> ... I forgot the very basic...
[18:14:13] <Casper> and now need to fix the ldscript thing again...
[18:17:00] <Brittany> no idea who pickletown is
[18:17:14] <Brittany> though I can assume he's probably in my class.
[18:17:20] <Fleck> ;pp
[18:17:53] <Tom_itx> well he was asking the exact same questions
[18:18:22] * Tom_itx hi fives Fleck
[18:18:51] <Fleck> cheers!
[18:20:02] <Brittany> made a post to my classes Facebook group calling out pickletown
[18:20:05] <Brittany> whoever the hell that is.
[18:20:19] <Tom_itx> read the logs here and you can see what he was asking
[18:20:24] <Tom_itx> mostly yesterday
[18:20:34] <Tom_itx> zlog
[18:21:18] <Brittany> haha 12mhz
[18:21:22] <Brittany> YEP that's our classes board.
[18:25:38] <Casper> ... the fading code is already done o.O it... can't... be... real... that?
[18:27:11] <Casper> and the code do compile...
[18:27:43] <Casper> 138 bytes... I beleive gcc optimised something out
[18:31:53] <rue_more> if you used -o3 I can be sure of it
[18:33:14] <Casper> rue_more: did you saw my question about the wire?
[18:37:48] <rue_more> no I couldn't find it
[18:38:10] <rue_more> oh
[18:38:21] <rue_more> anything below 5' has to be armoured cable
[18:38:54] <rue_more> if its comming out of the ground it also has to have something like ridgid pipe around it where it comes out (weed eaters and such)
[18:40:32] <Casper> I'm installing a new outlet outside, will be screwed on the concrete
[18:41:09] <Casper> so the questions are: from inside to it, can I use standard wire in a conduit or must it be special wire? I beleive standard since it's not burried right?
[18:41:35] <Casper> second question, is there a minimal distance from the ground to the outlet? I'm worried that it will be too low...
[18:42:24] <Casper> Tom_itx: global variables make the code grow?
[18:42:26] <rue_more> I dont think there is a min distance to the ground,
[18:42:38] <Tom_itx> probably so
[18:42:48] <Tom_itx> aren't they permanent?
[18:42:55] <Casper> went from 138 bytes to 238 bytes...
[18:43:04] <rue_more> the rule changed on putting lumex in pipe, I think you can now
[18:43:33] <Casper> k
[18:43:54] <rue_more> are you in canada or usa?
[18:43:59] <Casper> canada
[18:44:09] <rue_more> ok
[18:44:23] <rue_more> we have lots of customizations on top of the international code
[18:45:02] <Casper> you know that I think it's the EFF that is bringing the NEC code into court?
[18:45:14] <rue_more> should I feel like a jerk for sniping things on ebay?
[18:45:41] <mdszy> sniping isn't something to feel bad about
[18:45:46] <Casper> the nec code is copyrighted, it has been made into a law... and a law can not be copywritted
[18:47:58] <rue_more> an electrician puts a electrical outlet on an outside wall
[18:48:13] <rue_more> a gas fitter comes and puts a gas meter on the wall over the outlet
[18:48:29] <rue_more> electrical code says min distance to anything gas related is like 2m
[18:48:41] <rue_more> gas code has no such rule
[18:48:52] <rue_more> so, who/what is wrong?
[18:49:16] <Lambda_Aurigae> the general contractor or homeowner.
[18:49:31] <Casper> hmmm I beleive the gas guy is at fault there
[18:49:42] <Lambda_Aurigae> actually, yeah, he would be.
[18:49:47] <rue_more> but there is no code saying he cant do that
[18:49:52] <Lambda_Aurigae> but ultimately it's the fault of whoever is coordinating them.
[18:49:52] <Casper> yes
[18:49:56] <Casper> the electrical code say so
[18:50:10] <Casper> which that section he should be aware
[18:50:13] <rue_more> and the electrician had no preknowledge of it
[18:50:25] <Lambda_Aurigae> gas contractor should know better.
[18:50:41] <rue_more> so your oppinion is that the gas fitter is bound by the electrical code even tho he isn't an electrician?
[18:50:48] <Casper> yes
[18:50:49] <Lambda_Aurigae> yup.
[18:50:58] <Casper> the electrical code is made into law
[18:51:02] <Casper> he have to respect the law
[18:51:05] <Lambda_Aurigae> and the overseer, general contractor, whoever is also responsible.
[18:51:22] <rue_more> what if its two completely seperate calls, over a month
[18:51:26] <rue_more> different renos
[18:51:50] <Lambda_Aurigae> no general contractor? then the gas fitter.
[18:52:43] <rue_more> :) in the actual case, the electrical box hadn't been finished, the electrician capped it up and blanked it off
[18:52:44] <Casper> the gas guy is responsable
[18:52:57] <Casper> oh
[18:53:07] <Casper> so in that case it was legal to put the gas there
[18:53:13] <Casper> I think
[18:53:19] <rue_more> but its an interesting thing that comes up
[18:53:27] <rue_more> he knew it was gonna be a plug
[18:53:39] <Casper> it wasn't a plug
[18:53:47] <rue_more> the homeowner was pissed that he couldn't have his outdoor plug
[18:53:47] <Casper> so he was alloweds to put it there
[18:53:50] <Casper> however
[18:54:11] <Casper> I'ld have called the gas compagny to have the gas relocated at no charge
[18:54:19] <rue_more> ;)
[18:54:34] <Casper> or them pay the electrician and related work to have the outlet relocated
[18:54:43] <rue_more> I wonder if I could sell a small conveyor belt on ebay
[18:54:50] <Casper> why not?
[18:54:51] <Lambda_Aurigae> probably.
[18:55:00] <Lambda_Aurigae> I've seen stranger things sold on ebay..
[18:55:07] <rue_more> I'm pondering building one for the robot arm
[18:55:35] <Casper> hmmm look like I'll be forced to use 16 bits PWM
[18:56:14] <rue_more> http://www.ebay.ca/itm/Oriental-Motor-11-5-X-5-Linear-Belt-Conveyor-w-6-Watt-Motor-/131178625863
[18:56:22] <rue_more> hahaha it moves stuff 8 inches
[18:56:52] <Lambda_Aurigae> but it's from canada!
[18:57:18] <Lambda_Aurigae> that's not a conveyor belt...that's a treadmill for miniature poodles.
[18:57:28] <rue_more> hahaha
[18:58:46] <rue_more> not many functional conveyor belts on ebay
[19:35:51] <The_Coolest> hey guys, ATmega's have got clamping diodes on pins, right?
[19:36:36] <The_Coolest> What value resistor do you think I should use to make that if the diode has to clamp 12v the chip won't die (if possible)
[19:42:31] <Lambda_Aurigae> they have clamping diodes?
[19:42:52] <Lambda_Aurigae> you should never feed an avr with 12V...they don't like it much.
[19:44:09] <The_Coolest> Lambda_Aurigae yes i tried that once
[19:44:37] <The_Coolest> the results pissed made want to cry
[19:44:46] <The_Coolest> =pissed :D
[19:45:01] <The_Coolest> wow I fubared that 1
[19:45:14] <The_Coolest> the result made me want to cry*
[19:45:54] <clixxIO> sorry - just came in, what result?
[19:46:12] <Lambda_Aurigae> feeding 12V to a hungry AVR
[19:46:44] <jadew> you can feed 12V just fine
[19:46:53] <jadew> as long as you have a proper resistor in there
[19:47:45] <The_Coolest> jadew that's what i asked
[19:48:28] <jadew> make sure it doesn't have to sink too many mA
[19:49:37] <The_Coolest> jadew plan is: I'll have an opamp with a ±12v supply. wanna measure the voltage output of said opamp. The output *should* be 0 - 1v, but then again if things go screwy I want to make sure the chip doesn't fry.
[19:50:23] <The_Coolest> 10k resistor should do the job, no?
[19:54:19] <clixxIO> an interesting thing I found about AVR's is that they get power-overflow on the data pins
[19:54:34] <clixxIO> I have one that runs on absulutely no VCC at all
[19:54:48] <clixxIO> just power bleed from a serial pin
[19:55:15] <jadew> sorry, can't talk
[19:56:15] <The_Coolest> clixxIO yup. i did that too :)
[19:56:30] <The_Coolest> it even ran an lcd
[19:56:41] <The_Coolest> with weak backlight
[20:00:28] <clixxIO> I'm adding a Solar Panel to my AVR next
[20:00:53] <clixxIO> I found some keyring solar panels that are just the right size and pump out 3V
[20:00:56] <jadew> back
[20:01:03] <jadew> sorry, couldn't really talk
[20:01:15] <jadew> I don't know, I guess a few mA should be fine
[20:01:29] <jadew> I would do more than 1mA tho...
[20:01:31] <The_Coolest> heh
[20:01:42] <The_Coolest> then 24k it is :)
[20:01:47] <jadew> as for powering it from the IO pins, yeah, that should work because of the clamping diodes
[20:01:54] <jadew> they redirect overvoltage to VCC
[20:02:02] <jadew> so if you have nothing on VCC
[20:02:15] <jadew> you get power via the high clamping diode
[20:03:16] <jadew> *wouldn't
[20:06:09] <The_Coolest> yeah i got that part
[20:07:00] <jadew> what are you doing?
[20:07:14] <clixxIO> so why not run the 12V to a pin with clamping diodes? [note how I am asking others to run risky experients]
[20:07:34] <jadew> because it doesn't clamp it to 5v
[20:07:38] <jadew> it clamps it to vcc
[20:08:10] <jadew> if you have no vcc, it clamps it to 12 V
[20:08:15] <jadew> so you end up powering it up from 12 V
[20:11:12] <The_Coolest> oh
[20:12:14] <jadew> an interesting experiment to make would be to take an unpowered AVR chip and apply a voltage to one of the IO pins
[20:12:21] <jadew> and measure the voltage on the VCC pin
[20:12:27] <The_Coolest> jadew well. i'm not sure, there shouldn't be a situation where there's output on the opamp without the chip having vcc
[20:12:37] <jadew> my guess is that it will be about 0.7 V lower than what you put in
[20:12:57] <jadew> The_Coolest, I was answering to clixxIO
[20:13:04] <Lambda_Aurigae> if you need to clamp an input and guarantee it won't go over 5V, use a zener diode.
[20:13:08] <jadew> I don't think you need to worry about it with your setup
[20:13:40] <jadew> actually, I'm gonna do that experiment right now
[20:13:42] <The_Coolest> ig
[20:13:45] <The_Coolest> oh*
[20:14:05] <The_Coolest> Lambda_Aurigae ya
[20:14:22] <The_Coolest> trying to cut pcb space and complexity :P
[20:14:36] <Lambda_Aurigae> one zener vs one resistor...
[20:15:03] <The_Coolest> you'll need a resistor either way
[20:15:43] <The_Coolest> also 2 zeners, since it needs to be able to clamp to -12v too
[20:16:17] <clixxIO> what is the project again?
[20:16:45] <Lambda_Aurigae> -12V will just short through the zener.
[20:17:06] <Lambda_Aurigae> hmm..maybe the wrong way though.
[20:18:41] <The_Coolest> should test it
[20:21:12] <The_Coolest> Lambda_Aurigae it'll drop below 0v because of zeners Vf
[20:23:49] * Casper tought that using 16 bits PWM would be a problem
[20:23:57] <Casper> it's actually a problem solver!!!
[20:24:06] <The_Coolest> oh?
[20:24:22] <Casper> I'm making a led fader.... 256 levels
[20:24:28] <Casper> with a "global dimmer"
[20:24:42] <The_Coolest> ah
[20:24:56] <Casper> so, with 8 bits I have to basically do value * brightness / 256
[20:25:00] <clixxIO> Casper: which mcu?
[20:25:03] <The_Coolest> 16 bits gets you more values
[20:25:19] <Casper> with 16 bits, I just have do to value * brightness
[20:25:38] <Casper> clixxIO: most likelly a mega88pa
[20:26:18] <clixxIO> ah. I'm quite a fan of the Attiny85 now
[20:27:04] <Casper> by using very unoptimised code... I still have lots to do, but the fading code is 238 bytes...
[20:27:14] <Casper> could easillyt have went with a tiny
[20:27:22] <Casper> which I actually might do
[20:27:30] <Casper> I found out that I'm out of mosfet
[20:27:37] <Casper> so need to make a digikey order
[20:28:07] <clixxIO> why not use an RGB led?
[20:28:27] <clixxIO> like a WS8012 or whatever they are?
[20:28:35] <The_Coolest> clixxIO I'm sort of in the process of porting usbasp to the tiny85
[20:29:08] <clixxIO> cool
[20:29:34] <clixxIO> has anyone done that?
[20:29:43] <Lambda_Aurigae> probably.
[20:29:43] <The_Coolest> dunno
[20:29:50] <The_Coolest> it's not very difficult
[20:30:06] <The_Coolest> it mostly just compiles once you throw out all the crap
[20:30:27] <The_Coolest> i couldn't get it down to below 4kb to fit a 45 tho :P
[20:30:54] <clixxIO> Here's my remote LED controller for Attiny85 with a serial interface : https://github.com/clixx-io/clixx.io/tree/master/examples_attiny/serialcontroller
[20:31:03] <Casper> clixxIO: I do have RGB leds, I want a fader
[20:31:22] <clixxIO> fading is black
[20:31:59] <clixxIO> At the moment, I wouldn't mind led fading in the above project too
[20:32:21] <Casper> well, bbl
[20:32:26] <The_Coolest> clixxIO http://i.imgur.com/qDyNWrz.png
[20:32:35] <clixxIO> from a serial terminal, you just type 'd1o=0' to turn off 'd1o=1' to turn on
[20:33:13] <Casper> clixxIO: what I will do is: it's for a garden light, so eventually, it will have a photoresistor...
[20:33:43] <clixxIO> aha
[20:33:44] <Casper> when the sun is about to dissapear, the light will turn full on, then as the sun dissapear the lights will become dimmer
[20:34:03] <Casper> so that you see it earlier, and won't blind you at night
[20:34:17] <clixxIO> cool
[20:34:30] <Casper> also, since it's RGB, it will change of color continuously
[20:34:56] <clixxIO> yeah
[20:35:15] <Casper> the code to change the color is damn easy and dumb :D
[20:36:48] <Casper> http://bpaste.net/show/259616/ <=== the code so far
[20:36:56] <Casper> and yes, it do nothing right now
[20:37:32] <clixxIO> oh well
[20:38:11] <Casper> but atleast the main code is there
[20:38:28] <Casper> the delay routine will read the ADC and use one channel for the delay
[20:38:57] <Casper> bbl
[21:00:12] <clixxIO> I should make up my own Garden Light - I can now
[21:00:45] <clixxIO> that's a good excuse to make more Attiny85 processor boards made
[21:38:14] <clixxIO> morning eatyourguitar
[21:38:23] <eatyourguitar> hello
[21:38:35] <eatyourguitar> I have not been building much avr lately
[21:38:52] <eatyourguitar> my autojoin still has this room though
[21:38:54] <clixxIO> oh well
[21:39:01] <eatyourguitar> I stiill like avrs
[21:39:27] <eatyourguitar> but lately all the pcb's I do have not had a need for it
[21:39:29] <clixxIO> I'm extracting fun from mine still
[21:40:00] <eatyourguitar> I actually like to play with obsolete cmos
[21:40:38] <clixxIO> what's so different from avr's?
[21:41:09] <eatyourguitar> I don't need to do any code
[21:41:11] <clixxIO> avr's are definitely obsolete
[21:41:37] <clixxIO> ah I see
[21:41:39] <eatyourguitar> but you can get simple avr small and cheap
[21:41:44] <eatyourguitar> $0.30
[21:41:53] <eatyourguitar> 8 pin sot
[21:42:51] <clixxIO> right, I'm investing a lot of time into attiny at the moment
[21:42:57] <clixxIO> for that reason
[21:43:08] <eatyourguitar> 8 pin?
[21:43:40] <clixxIO> yeah
[21:43:55] <eatyourguitar> I was thinking the other day that I might need to use it for an analog to PWM
[21:44:07] <clixxIO> well for deployment they're great
[21:44:35] <clixxIO> yeah, that's a sort of classic use case
[21:45:36] <clixxIO> of what they would be great at
[21:46:45] <clixxIO> I was pfuffing all yesterday with the Attiny85 ADC
[21:48:01] <clixxIO> I'm trying to get ADC -> IoT working
[21:48:03] <eatyourguitar> the lower voltage avr's are actually more versatile for what input voltages you can use on the adc
[21:48:18] <eatyourguitar> cause you can resistor divider higher input voltages
[21:48:38] <eatyourguitar> but you need to amp the signal to use low voltage sensors
[21:48:54] <eatyourguitar> so like a 3.3v is just better than 5v
[21:50:49] <clixxIO> exactly
[21:53:16] <clixxIO> This is close to the setup I'm using : https://plus.google.com/109366813998920635083/posts/UGQrTYzcg3T
[21:55:09] <clixxIO> I should make an easy-to-use voltage-divider board that clickes right in
[21:56:55] <clixxIO> after I get back from Japan maybe
[21:58:30] <eatyourguitar> fun project
[21:58:49] <eatyourguitar> is the display driver in the display?
[21:59:50] <clixxIO> ah, that's actually a voltmeter from china. I think they are using a pic
[22:00:33] <clixxIO> then the voltmeter is attached to one of my boards piggyback
[22:00:47] <clixxIO> to measure line or input voltage
[22:01:02] <clixxIO> handy for debugging
[22:02:01] <eatyourguitar> knightbright makes some pretty sweet displays
[22:04:07] <clixxIO> there's lots of displays that I do want to do
[22:04:22] <clixxIO> just had other things to work on
[22:27:24] <Casper> it always amaze me to see the datasheet size of such a small chip...
[22:27:47] <Casper> now... imagine the datasheet for an I7 :D
[23:12:40] <dgriffi> I'm back at trying to understand debouncing a 4x4 key matrix
[23:13:06] <dgriffi> Would someone please take a look at http://stackoverflow.com/questions/23463542/?
[23:15:45] <clixxIO> what's the problem?
[23:16:31] <tzanger> Casper: they're called databooks and they're huge
[23:20:09] <dgriffi> clixxIO: I have a 4x4 key matrix reader working, but not the debouncer
[23:20:37] <Casper> databooks... plurials :D
[23:20:45] <tzanger> debouncing 16 keys isn't any different than debouncing one key
[23:20:46] <Casper> but yeah... I can imagine
[23:20:57] <tzanger> you can use tricks to be more efficient at it but for now stick to simple
[23:21:21] <dgriffi> Here's what I have: http://pastebin.com/s7kyhJY5
[23:21:27] <Casper> a simple microcontroller.. 8 bits, with most of the interface internal and "undocumented" since it's not needed... is 600+ pages...
[23:23:22] <dgriffi> the first if statement in getkey() seems to work. But if I move that code into the second if statement and delete the first, I get spurious values sent back when a key is released (about a third of the time)
[23:24:21] <tzanger> dgriffi: http://pastebin.com/KvyYpT04 is a very simple debouncer. it's not particularly efficient but it gets the job done nicely and is understandable
[23:26:50] <dgriffi> tzanger: what am I doing wrong in my code?
[23:31:09] <Casper> hmmm do I use RTC or do I use dumb delays....
[23:31:19] <Casper> both are tempting
[23:32:50] <Casper> a real rtc only need to use like 8 bytes of ram for a very accurate one
[23:36:42] <clixxIO> you mean a Real-time-clock?
[23:43:32] <Casper> ya
[23:44:32] <Casper> I'll use dumb delay
[23:47:53] <clixxIO> What about reading the time over IoT?
[23:47:59] <clixxIO> from some server
[23:49:51] <Casper> that would require network connection
[23:51:50] <Casper> hmmm I'll use the RTC...
[23:55:33] <clixxIO> network connections are getting cheaper these days
[23:55:51] <clixxIO> just bluetooth HC05
[23:56:00] <clixxIO> $3 or so
[23:58:58] <clixxIO> I'm more just talking to myself, not saying you have to do it that particular way