Back
[00:27:32] <DanFrederiksen> how temperature sensitive is the internal clock in atmega?
[00:46:22] <DanFrederiksen> interesting video about precision of internal and external clock
http://www.youtube.com/watch?feature=player_embedded&v=DHwt_ioVavE
[01:11:45] <jadew> w|zzy, fixed some bad bugs with the displayed times, also added more options to the context menu when you're selecting something: dumb.ro/files/lafront/OLSFront.zip
[01:28:37] <RikusW> M$ made installs so much bigger and "better" these days, seems like its optimized to use the maximum amount of cpu cycles :-P
[01:33:48] <AnalogSound> :))
[01:34:54] <RikusW> Compare that to the Thunderbird or Firefox installs which complete in under 60s even on an older PC....
[01:36:51] <AnalogSound> anyway is all BS... now i use Aurora but still i get big memory usage ... and i can't see why
[01:39:21] <RikusW> lazy programmers and cheap RAM
[01:39:43] * RikusW thinks back to the P1 16MB RAM days.....
[01:40:32] <AnalogSound> they should go bag to ASM and pure C/C++
[01:42:15] <RikusW> yep
[01:42:31] <RikusW> rather leak memory than eat all of it :-P
[01:43:33] <RikusW> its a pity this is so expensive ->
http://www.labcenter.com/ordering/cprices.cfm
[02:28:38] <w|zzy> context menu for the win jadew...
[02:28:43] <w|zzy> Did i reignite your passion?
[02:48:40] <OndraSterver> RikusW, dude, even on 486 I had 32MB RAM :D
[02:56:32] <OndraSterver> into PI I stuck ... 128MB? 192MB?
[02:56:36] <OndraSterver> I had two 32MB sticks
[02:56:41] <OndraSterver> and I don't remember more
[03:10:21] <RikusW> OndraSterver: then you have a BIG 486 PC :-P
[03:13:42] <OndraSterver> :D
[03:13:50] <OndraSterver> I still have the motherboard and CPU and RAM somewhere
[03:13:56] <OndraSterver> maybe even the GPU and drive controller
[03:14:02] <OndraSterver> if not, I have plenty others in my cabinet :P
[03:25:25] <tld> I got a LCD-panel in the mail today, but a couple of pins are pretty banged up. Should I hold the seller responsible, for poor packaging (it really was poor), or should I just replace the pins, and not make too much of a fuss about it?
[03:27:32] <OndraSterver> both
[03:28:12] <tld> isn't that kind of sneaky?
[03:28:19] <tld> I'm just thinking this could be a lot of money for the seller.
[03:28:33] <OndraSterver> just notify him that he effed it up
[03:28:38] <OndraSterver> and he should fix that :P
[03:36:28] * RikusW got a mouse button with keybounce :S
[03:36:40] <RikusW> random multiple clicks :S
[03:37:45] <RikusW> http://www.dpd.cdc.gov/dpdx/HTML/ImageLibrary/A-F/Artifacts/body_Artifacts_il9.htm
[03:38:09] <RikusW> or google -> mosquito wing microscope photo to see something really cool
[03:38:19] <RikusW> in google images
[03:45:57] <tld> OndraSterver: notified.
[03:46:01] <tld> OndraSterver: thanks for input. :)
[03:46:10] <OndraSterver> np
[03:47:49] <tld> no worse than this:
http://elde.net/f/lcd-broken-pins.jpg
[03:48:10] <tld> which is why I have a bit mixed feelings about complaining too much
[04:08:50] <RikusW> now these needs some debugging :-P
http://www.dpd.cdc.gov/dpdx/HTML/ImageLibrary/Fleas_il.htm
[04:18:50] <tld> http://www.ebay.com/itm/251057269544?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649 <-- I think I like it.
[04:22:42] <OndraSterver> hehe
[04:22:52] <OndraSterver> what micro are you connecting to it?
[04:24:39] <tld> none yet
[04:25:09] <tld> I'll probably whack up some underpowered atmega328p + 2x 74hc595 thingy, just to test it out, see if I can get the protocol right.
[04:25:30] <tld> for slow graphing and the like, it might be okay, not sure yet.
[04:29:22] <specing> ARM
[04:41:57] <tld> I'll probably ditch atmega in favor of a mix of attiny or msp430, and arm, at some point.
[04:42:08] <tld> right now the LCD is just for playing, so I get to know the thing, before I need it.
[04:51:27] <e2580> Anyone interested in a sneak peek at a hardware based security device we are about ready to release?
[04:52:07] <e2580> We are also looking for developers for the project, if you have skill with at32uc3a3256s and aes, i got work for you :)
[05:46:24] <e2580> Anyone interested in a sneak peek at a hardware based security device we are about ready to release?
[05:50:29] <vsync_> e2580: yeah we have those already
[05:50:34] <vsync_> they're called Locks
[05:53:36] <e2580> hardware implies computer hardware
[05:53:41] <e2580> not a physical lock
[05:54:09] <e2580> check it out www.cryptx2.com
[05:54:22] <e2580> built on at32uc3a3256s
[06:06:13] <e2580> any feedback ?
[06:06:40] <tld> I was quite interested.
[06:06:45] <tld> then this killed it: "Due to export regulations we cant ship the micro-controller that is used in the CryptX2 outside the USA."
[06:06:57] <vsync_> I still prefer Locks
[06:07:41] <e2580> yes, the export thing is annoying
[06:07:52] <e2580> but, expect to see vendors in other countries VERY soon ;)
[06:08:23] <e2580> we also will sell bare pcbs, and devices that are missing the mcu, so you can just add your own
[06:08:40] <e2580> since the device is open source, you can make your own too
[06:10:01] <tld> You've done some things right though, I'll admit
[06:10:37] <e2580> please tell me what you dont like, i am interested in hearing how to improve
[06:11:47] <tld> Hardware-wise, I'd have preferred something like one internal micro-SD, external micro-SD and/or SD slot, and USB-passthrough.
[06:11:54] <tld> so you could use it with USB sticks for example.
[06:11:59] <tld> or harddrives for that matter.
[06:12:11] <tld> (I'm ignoring chip-limits, just talking about what would have been nice).
[06:13:10] <tld> also, with just 5 keys, you'd need some kind of "4 wrong PINs, and the key gets wiped"
[06:13:13] <tld> not sure if there is such a thing
[06:13:15] <tld> but it should be
[06:13:22] <tld> and finally, your security model is flawed.
[06:13:26] <tld> you *need* a stick to use things.
[06:13:30] <tld> which easily leads to data-loss.
[06:13:38] <tld> you should be able to generate the key on the device, *or* set it
[06:13:57] <tld> if you set it, you know the key, and it could be used to access the data using software on a PC, as a worst-case-recovery kinda thing.
[06:14:03] <tld> that's also what'll keep you out of enterprise-use.
[06:14:05] <tld> (bbiab)
[06:14:24] <e2580> tld, ;) usb 2 usb version is in the works
[06:14:52] <e2580> also, 10 bad passkey entries will destroy the salt. so data is useless
[06:16:23] <e2580> we do not offer data recovery. that is not the device goals we are going for
[06:16:35] <e2580> our device is security over easy of use
[06:16:50] <e2580> you can make your own backups
[06:16:54] <e2580> in a few ways
[06:17:35] <e2580> you can dd or image the sd cards. you wont be able to decrypt them without the device, but if the cards get lost or corrupt then you have backups
[06:17:41] <Horologium> I will stick with physical security and/or not putting sensitive information on a device that I might stick in my pocket and lose.
[06:17:54] <e2580> or you can decrypt and attach to pc and just copy the files someplace else
[06:18:37] <Horologium> and any encryption can be broken if someone has the processing power and some time.
[06:18:54] <e2580> yes, your use case will decide if this is the kind of device for your needs
[06:19:20] <e2580> well, yes, you can bruteforce aes, but at last count it will take longer than the age of the universe to do
[06:19:48] <e2580> i am open to any methods you think may work to attack it...
[06:19:57] <Horologium> devices like this, while interesting fun projects to work on, encourage people to put sensitive information on them and think they are secure then lose them and find out 6 months later just how not secure the data is when someone posts their information on the internet.
[06:20:19] <e2580> i would like to find someone with the skill to crack this device
[06:21:51] <karlp> e2580: once you've "unlocked" your device, isn't it readable by anyone on that machine as just another disk?
[06:21:57] <e2580> this has been through peer review with MANY security specialists, 2600 members, people in info sec etc.. so far no one has idea for method of attack besides beat the taget into submission :)
[06:22:22] <e2580> yes, when unlocked and in the pc, you can read the data just like any other disk.
[06:22:49] <Horologium> the salt is stored in flash on the microcontroller, yes?
[06:23:18] <e2580> the device is made to secure data at rest, not be some kind of anti virus, anti trojan, but you can run a secured os from the drive, like a live cd
[06:23:49] <e2580> yes, the salt is stored on the mcu, in secure memory. you cant read it, and you cant reprogram the mcu without a full erase first
[06:27:37] <tld> "also, 10 bad passkey entries will destroy the salt. so data is useless" <-- that really should be under "Why is this thing secure" in the FAQ.
[06:27:55] <e2580> not finished with the faq yes
[06:27:58] <e2580> yet
[06:28:10] <e2580> also, you can adjust that # in the source code
[06:28:30] <tld> "we do not offer data recovery. that is not the device goals we are going for" <-- but it's what individuals will want, and enterprise need… That is, you could give them the option. It doesn't compromise security in any way, as long as the customer securely handles the key.
[06:29:06] <e2580> there is no way to do data recovery without opening the door to attack
[06:29:40] <e2580> enterprise is made of IT professionals that often have their own tools
[06:30:16] <e2580> if they are in a company with strict rules like that then no, they may not be allowed the device, but we cant make a device for eveyone
[06:30:26] <tld> yes, they often do have their own tools. someone made those tools, and yours could be one of those tools.
[06:30:46] <tld> for my own use, the thing is worthless the way it is now.
[06:30:53] <tld> only way I'd stick data on it, is if it's important.
[06:30:58] <tld> if it's important, I'd want recovery option.
[06:31:05] <e2580> our most important goal is security over all else
[06:31:07] <Horologium> do the devices use different internal keys and salt or are they all the same? meaning, can you take SD from one and put it in another and read it?
[06:31:15] <e2580> no
[06:31:30] <e2580> when you format the device it creates a new salt
[06:31:36] <tld> If the device goes bust, it doesn't help me if I have an encrypted copy of the SD, I can't even order a new cryptx2-thing and use that for recovery, or keep a backup around.
[06:31:52] <tld> so… worthless…
[06:32:06] <tld> *so damn close*, but in the end, it just doesn't have a place in my lineup of tools.
[06:32:16] <tld> I also have a problem with things I can't key myself.
[06:32:19] <e2580> no, you cant decrypt your data with a different cryptx2, it must be yours, and it must not have been reformatted, or reflashed.
[06:32:42] <tld> if I could use a secure machine to make the key, make the salt, set those, split them, store them in secure places, so I could recover using software or another cryptx2, I'd really love the thing.
[06:32:45] <Kevin`> tld how exactly would you recover data from the device without key escrow
[06:32:49] <e2580> by reformeted, i dont mean the sd card, i mean the passkey cant be changed
[06:32:57] <Horologium> so it might be useful for transporting information but not for day to day use in an office.
[06:32:59] <tld> that's what I said… I can't with another crypts. which is a problem.
[06:33:38] <tld> Kevin`: If I could set key+salt, I could store those securely, and set them on a new cryptx2, or use software, to access the data.
[06:33:41] <e2580> you can do backups of the card with dd or imaging tools, that will solve the issue of lost of corrupted cards
[06:33:51] <vsync_> This is why locks are more reliable. Can be integrated with a recovery system called Copies. Also protected with a Lock, at another Location!
[06:33:53] <tld> yes, but not of lost cryptx2.
[06:33:54] <e2580> you can also backup the data in normal ways once decrypted and plugged into pc
[06:34:04] <Kevin`> tld: from my understanding of the device it would be pretty trivial to allow writing the salt from the host
[06:34:15] <tld> Kevin`: I think so too
[06:34:21] <tld> Kevin`: which is why I'm trying to suggest it
[06:34:32] <tld> Kevin`: So they don't get a bad rep, and ruin their business.
[06:34:52] <tld> I'm not saying make it mandatory, just make it possible.
[06:35:09] <e2580> you can change the source to use your own salt, so you can recreate the same device if you want. but thats not standard operation. that would be your own custom firmware
[06:35:23] <tld> Yes, *I* could do that.
[06:35:32] <tld> but that doesn't solve your problem.
[06:35:33] <e2580> we will prvide all source code, and we will have several versions
[06:35:57] <tld> just *please* consider having a version from the get-go, with key handling like that?
[06:36:03] <tld> it really makes a world of difference, to a world of people.
[06:36:14] <e2580> please explain exactly what you would like
[06:36:45] <tld> In the simplest form, I'd like to be able to set key+salt (set, possibly re-set).
[06:36:51] <tld> that's really all it takes.
[06:37:11] <tld> if I can do that, I could set a key+salt, that I could store securely, and it'd enable key-management for me.
[06:37:29] <tld> I could store it securely written down somewhere, such as 1/4th of the key in 8 secure locations, or whatever.
[06:37:54] <tld> if the thing gets lost, I die, someone steals it (but I have other SD-cards linked to it), I could then recover from that situation.
[06:38:15] <tld> I could get a new cryptx2, collect the key-material, program it up with that, and access the SD-card(s) I still have.
[06:38:29] <tld> as an example: let's say I have two SD-cards, for backup.
[06:38:34] <Kevin`> oh, on that note
[06:38:39] <tld> I bring one with me, I regularly do backups to the other, which I leave in the office.
[06:38:45] <tld> Then I go on vacation, bringing work-stuff with me.
[06:38:46] <e2580> hmm, that is a good idea. i will add that to our alternate firmware list. but for the default firmware, i dont think thats a good option to start with
[06:38:49] <tld> someone steals the device.
[06:38:51] <Kevin`> e2580: it would likely be useful to have the ability to access the encrypted devices raw
[06:39:07] <tld> if I could somehow still get the key, I could then use another cryptx2, access the backup I had on the card at the office.
[06:39:11] <tld> see what I mean?
[06:39:14] <Kevin`> e2580: for backups and such
[06:39:27] <Kevin`> e2580: rather than having to remove them and use a different reader
[06:40:19] <tld> people *will* eat you alive if you don't include something like that, I'm betting $0.02 on it!
[06:40:28] <e2580> ok, that is also a good idea for unencrypted read mode
[06:40:42] <tld> if you don't have it ready to go (which I can understand, it'd involve software efforts etc, takes time), at least make a note that it's coming.
[06:40:51] <e2580> hehe i should hire you for development on this lol
[06:41:22] <tld> I've been working with infosec on-and-off for a lot of years.
[06:41:39] <e2580> i will surely add these 2 functions to the list for alternate firmware. i would love to hear any other ideas you got
[06:41:52] <tld> Kevin` mentioned raw…
[06:41:53] <e2580> these are fairly simple to add in
[06:41:57] <tld> at what layer is the encryption done?
[06:42:08] <e2580> block level
[06:42:11] <tld> nice. :)
[06:42:15] <tld> that, I like a lot.
[06:42:22] <e2580> you can use any file system
[06:42:33] <e2580> also, we plan to have the device type able to be changed
[06:42:39] <e2580> so, it can be a cdrom or other
[06:42:46] <tld> :)
[06:42:49] <tld> what speeds do you get?
[06:43:05] <e2580> nearly full speed of the sd card used
[06:43:18] <e2580> the mcu we use has a aes crypto acceperator on it
[06:43:22] <tld> :)
[06:43:27] <e2580> the bottleneck is the sd cards
[06:43:41] <e2580> i am also experimenting with raid 1/0
[06:43:50] <e2580> and sdxc
[06:44:04] <Kevin`> oh, you didn't answer this before I think, are you using spi or wide sd?
[06:44:33] <Kevin`> the wonderful thing about sd cards is they are so slow it hardly matters, but i'm curious :)
[06:44:49] <e2580> mci
[06:44:50] <karlp> by wide sd, you mean sdio?
[06:44:51] <e2580> 4bit
[06:44:57] <e2580> not sdio
[06:45:01] <Kevin`> karlp: sdio can work with 1 bit
[06:45:21] <e2580> sdio is a standard
[06:45:45] <e2580> we use sd msc (mass storage class device)
[06:46:10] <e2580> this allows us to play with the device type and use standard drivers
[06:56:02] <jadew> w|zzy, yeah, I was going to take a break for a bit, but I'm glad you asked about it
[06:57:53] <jadew> I'll have to make the selection stick around for a while, so you can right click on more channels and get different measurements
[06:58:07] <tld> how easy would it be to program this thing btw? Are there "normal" atmel ICSP-pins exposed?
[06:58:24] <tld> does it include any kind of USB-programmability?
[07:01:37] <tld> how are you using AES btw?
[07:01:57] <tld> CBC? XTS?
[07:01:59] <e2580> you can program with DFU direct firmware upgrade
[07:02:04] <e2580> or jtag
[07:02:47] <e2580> no, we dont use xts, i wish it was available, but we are limited with the crypto accelerators modes it supports
[07:02:57] <e2580> we are currently looking into the mode for aes
[07:03:06] <e2580> your input will be greatly appreciated on the mode
[07:03:30] <e2580> we were thinking ctr, but were suggested cbc
[07:08:10] <tld> If you can't use XTS, I'd use CBC.
[07:08:15] <tld> and also warn about the issues.
[07:09:23] <tld> illustration of why ECB would be *horribly* bad:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
[07:11:11] <tld> with CBC, you'll have some issues, because blocks are XORed by the previous ciphertext-block before they're encrytped
[07:11:27] <tld> but you can work around that, by defining how much of the card you view as one encrypted segment.
[07:11:49] <tld> just use offset on the card as IV, so you don't end up back to the problem with ECB.
[07:12:23] <tld> there are a couple of good papers on how to do secure disk crypto by the FreeBSD guys.
[07:12:33] <tld> two systems, geli and gbde
[07:12:38] <tld> highly recommended.
[07:14:51] <e2580> ok, i will check that out
[07:15:15] <e2580> so far looks like cbc is the mode of choice with everyone i ask
[07:20:45] <day> im trying to flash with avrdude(linux) but im not sure which -P (Port) ive to use. most guides say /dev/ttyUSB* but i do not have any of those :/ lsusb lists my programmer(jtag ice mk2)
[07:21:01] <Kevin`> day: -P usb
[07:21:55] <day> Kevin: oh god...i swear ive tried that
[07:22:41] <Kevin`> needs to be done as root unless you have added suitible rules to modifify the permissions for the device
[07:23:12] <day> Kevin`: that might be it. i think i tried it in the very beginning :/
[07:23:20] <day> Kevin`: anyways its working now. ty
[07:44:14] <Amadiro> Has anybody ever implemented an isochronous interface with LUFA?
[07:46:59] <Amadiro> Hm, found some examples on google, doesn't look too icky
[07:59:33] <day> im still struggling with avr-gcc commandline compiling i managed to produce a *.out file from my original *.c file but im not sure how to generate the hex file
[08:02:39] <day> nvm got it :)
[08:35:30] <AR_> bonjour
[08:39:11] <AR_> simple code to read ADC and turn off LED if ADC value over 52
[08:39:13] <AR_> http://pastebin.com/LMJZfv25
[08:39:17] <AR_> on ATTiny45
[08:39:35] <AR_> however, when i high enough value is applied to the adc input, the LED flashes
[08:39:39] <AR_> doesnt stay off
[09:09:41] <tld> AR_: jitter? LED turns on, voltage drops, LED goes off, voltage rises, LED turns on, voltage drops… ?
[09:38:30] <JyZyXEL> http://pastebin.com/dvyVtuPD why doesn't this work?
[09:41:31] <DanFrederiksen> interesting video about precision of internal and external clock
http://www.youtube.com/watch?feature=player_embedded&v=DHwt_ioVavE
[09:42:03] <karlp> 12 minutes?
[09:42:30] <karlp> is it just going to say, "internal RC is only +-10%, that might matter"
[09:42:34] <AR_> tld, the LED is normally on, it should turn off and stay off when adch value is high enough
[09:42:38] <AR_> but it just blinks
[09:42:42] <AR_> fast
[09:55:25] <tld> I got some LT3080s, but now I can't find them. :/
[09:57:54] <DanFrederiksen> karlp, yeah it could be a lot shorter
[10:00:05] <karlp> also, it's a bit negative on it being inaccurate,
[10:04:30] <AR_> i'm a little confused on how people set register bits with shifts and ORs
[10:04:32] <Kevin`> DanFrederiksen: the xmega internal clock is more accurate, btw, if you find yourself on the edge of something
[10:04:32] <AR_> like
[10:04:43] <AR_> ADCSRA |= (1<<REFS0);
[10:04:46] <AR_> how does that work?
[10:07:02] <tld> you shift the 1 REFS0 bits to the left
[10:07:13] <DanFrederiksen> Kevin`, edge of something?
[10:07:20] <tld> that is, if REFS0 is 3, you shift 1 three places left.
[10:07:35] <DanFrederiksen> Kevin`, never mind, got it
[10:07:45] <tld> once you're familiar, it's a nice way to write it, since you wouldn't have to hard-code the three
[10:07:51] <Kevin`> DanFrederiksen: usb or rs232, for example, will sometimes be problematic with the internal oscillator on the older chips
[10:07:55] <tld> (and remember why there's a three there)
[10:08:37] <tld> |= sets ADCSRA to the result of what's on the right side of the equal, XORed with ADCSRA
[10:09:23] <tld> so if you have 00000001 in ADCSRA, and REFS0 is 3, you'd shift 1 three places left (00001000), XOR that with 00000001 and get 00001001, then put that in ADCSRA
[10:09:27] <tld> AR_: makes sense?
[10:10:05] <AR_> ohh ok
[10:10:06] <tld> basically readable for "set the bit REFS0 from the right-side to high in ADCSRA".
[10:10:15] <tld> "readable" I should say.
[10:10:29] <AR_> so (0 << REFS0) makes the REFS0 bit 0 also?
[10:10:43] <tld> well, no, not really
[10:10:48] <AR_> why not
[10:10:57] <tld> I lied to you, sorry.
[10:11:01] <AR_> :)
[10:11:02] <tld> was focus on something else
[10:11:05] <tld> |= is AND
[10:11:16] <tld> so you'd *set* the bit high, not XOR it high.
[10:11:23] <AR_> right
[10:11:33] <AR_> so how do you set a bit low
[10:11:44] <eric_j> AR_: tld is misleading you
[10:11:44] <tld> argh!
[10:11:45] <tld> OR
[10:11:49] <tld> I'm misleading
[10:11:49] <tld> yes
[10:11:50] <AR_> loooooool
[10:11:51] <eric_j> |= is OR
[10:11:52] <tld> sorry
[10:11:54] <AR_> i thought it was OR
[10:11:55] <tld> eric_j: and thanks.
[10:11:56] <Richard_Cavell> AR_: "set a bit low" means clear a bit
[10:11:58] <AR_> you were confusing me
[10:12:04] <AR_> yes Richard_Cavell
[10:12:14] <AR_> can i do that with the same type of statement
[10:12:17] <AR_> with a shift
[10:12:25] * tld shuts up until after sleep and coffee
[10:12:39] <AR_> i would have to XOR then, right?
[10:13:09] <AR_> ADCSRA ^= (1 << REFS0)
[10:13:11] <eric_j> AR_: to set the bit: ADCSRA |= (1<<REFS0);
[10:13:12] <AR_> if it was 1 already
[10:13:21] <eric_j> AR_: to clear the bit: ADCSRA &= ~(1<<REFS0);
[10:13:23] <AR_> how to clear
[10:13:23] <AR_> ok
[10:13:29] <AR_> ah yea
[10:13:31] <AR_> that does make sense now
[10:13:33] <AR_> thanks
[10:13:46] <AR_> i just havent been thinking straight lately
[10:13:55] <eric_j> XOR would toggle the bit but that is not usually what you want to do
[10:14:04] <AR_> right
[10:14:07] <tld> (C has no NAND, so just have to flip it around while setting, thus the bit more ugly way to clear the bit)
[10:14:18] <AR_> lol
[10:14:23] <tld> really sorry about misleading, I think I'm too tired to realize how tired I am, or something.
[10:14:28] <AR_> xD
[10:17:24] <JyZyXEL> ISR(USART_RX_vect) { tells me warning: return type defaults to ‘int’ and In function ‘ISR’: warning: type of ‘USART_RX_vect’ defaults to ‘int’
[10:17:32] <JyZyXEL> whats the proper way to define it?
[10:19:30] <AR_> lolwat
[10:23:12] <Steffanx> Which AVR do you use JyZyXEL ?
[10:23:47] <JyZyXEL> avr-gcc (GCC) 4.3.5
[10:23:49] <Steffanx> And do you include avr/interrupt.h ?
[10:24:06] <JyZyXEL> oh yeah...! :D
[10:25:21] <AR_> lol
[11:25:19] <TechIsCool> what do the unlock bit and lock bits do?
[11:27:22] <TechIsCool> I am being stupid there is no unlock bit its just the code to unlock the lock bit nvm
[11:47:03] <Tom_itx> they keep you from getting in
[12:15:27] <Tom_itx> http://www.pentalogix.com/smt-stencils.php?pcbsid=b77bf58b202e5d011a378ddf073c6f54s
[12:16:21] <Tom_itx> better quality than Co2 Laser
[12:30:33] <Steffanx> that website has to fix their code first Tom_itx
[12:30:38] <Steffanx> see error @ bottom
[14:21:13] <r0b-> hey guys
[14:21:52] <r0b-> how would i even START to write code to "flicker" an LED
[14:22:11] <AR_> pseudo code
[14:22:21] <AR_> int main(){
[14:22:33] <r0b-> pastebin... my client doesnt log
[14:22:35] <AR_> set_output_pin;
[14:22:43] <AR_> while(1){
[14:22:50] <AR_> led_on();
[14:22:55] <AR_> pause();
[14:22:59] <AR_> led_off();
[14:23:02] <AR_> }
[14:23:03] <AR_> }
[14:23:18] <r0b-> i mean like a candle...
[14:23:19] <AR_> pause again after off
[14:23:25] * r0b- can do it with Arduino but :P
[14:23:40] <AR_> can i see your arduino code to clarify?
[14:23:53] * r0b- hasnt started yet...
[14:23:55] <AR_> you want it to fliker in a pattern or randomly?
[14:24:02] <r0b-> random
[14:24:08] <r0b-> a candle type effect
[14:24:11] <AR_> or just appear random :P
[14:24:30] <AR_> well, you would just have to play with time delay values between the on/off
[14:24:33] <r0b-> arduino you cann analogWrite(led, random(120)+135);
[14:24:42] <r0b-> call*
[14:24:43] <AR_> oh i see what you want
[14:24:49] <AR_> PWM output
[14:24:53] <r0b-> yea
[14:25:13] <r0b-> i havent written a LICK of AVR LibC code
[14:25:14] <AR_> what microcontroller do you have
[14:27:09] <AR_> r0b-, see here
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=90507
[14:29:16] <r0b-> right now a mega328p
[14:29:18] <r0b-> with Arduino
[14:32:24] * r0b- used arduino code
[14:32:35] <r0b-> i got a flickering blue 3mm led...
[14:32:46] * r0b- is sacraficing
[14:32:51] <r0b-> it has NO LED resistor...
[14:33:35] <r0b-> :P
[14:33:44] <r0b-> analogWrite(led, random(255));
[14:33:57] <r0b-> at a random time delay
[14:34:07] <r0b-> produces a nice effect
[14:35:42] <r0b-> so i got my effect...
[14:38:01] <r0b-> what do you thinkg a good "delay" time would be?
[14:38:53] <r0b-> ty AR_
[14:39:39] <AR_> it is up to you
[14:39:43] <AR_> how long you want it on and off
[14:40:06] <AR_> thats the nice thing about microcontrollers
[14:40:09] <AR_> very flexible
[14:40:48] <AR_> also, you dont need a resistor on the LED on most microcontrollers because they can't output enough current to blow the LED
[14:41:53] <r0b-> arduino/mega328p outputs a max of 40ma per pin
[14:44:47] <specing> 40ma will still heat it up a lot
[14:45:01] <prpplague> r0b-:
http://www.cmiyc.com/tutorials/led-basics/
[14:45:21] <prpplague> r0b-: good tutorial on how to calculate if you need a resistor or not
[14:45:44] <r0b-> i know i need one
[14:45:52] * r0b- JUST testing... the effect
[14:46:05] <r0b-> the final will have resistor
[14:50:04] <r0b-> and more LEDs :P
[14:56:37] <asteve> resistors and LEDs eh?
[14:56:42] <asteve> it's almost like…it's alive
[14:56:46] <asteve> it can compute and shine
[16:10:38] <iscsinoob> is rue_mohr doing ok these days?
[16:19:48] <iscsinoob> sorry wrong button, did someone answer my question about rue_mohr
