Back
[00:01:02] <WormFood> Because you'll notice, that one vendor typically uses the same basic layout, for all their different models. Once you learn that layout, and you remember the backspace is in that unnatural position, and you adapt to it; now you can't use a regular keyboard, and insist on that brand.
[07:16:21] <_ami_> hello guys,
[07:16:25] <_ami_> whats up
[08:28:58] <eszett> hi!
[08:30:06] <eszett> I have a question. In my schematic i have a few decoupling caps at my Atmel (atmega32u4), one of them is mentioned in the datasheet of the Atmel, but i cant find the others mentioned. Where do i find them ?
http://92.217.184.127/gemini.pdf
[08:32:32] <cehteh> your schematics show the values
[08:32:58] <cehteh> its a bit odd this way but shouldnt be critical
[08:33:22] <eszett> Ye, those values are probably ok, but I'm looking for an official reference for these values
[08:34:04] <cehteh> iirc you wont references, because they depend also on the the application and environment you use
[08:34:40] <cehteh> when your mega drives a lot current on the outputs then bigger caps, when the environment is noisy too
[08:35:15] <eszett> so, when you dont have the experience to judge the values, you basically just copy them from other basic minimum circuit schematics, like I did?
[08:35:26] <cehteh> 'usually' i have 4.7µ tanals and 0.1µ ceramics for that, i bet that would work well there too
[08:35:48] <eszett> ok, so its common sense to use 0.1µ ceramics, didnt know that
[08:36:39] <cehteh> ceramics have low ESR they can suppy a current pulse very quickly
[08:36:57] <cehteh> they need to be physically close to these pins
[08:37:56] <cehteh> avcc should be decoupled with a inductor as well, thats somewhere else noted
[08:38:09] <cehteh> at least when you use the analog stuff
[08:38:13] <cehteh> if not, it wont matter
[08:39:01] <eszett> I dont use analog stuff, so i can spare me 2 caps on both AVCC, that is interesting..
[08:39:07] <cehteh> no
[08:39:11] <cehteh> you need the caps
[08:39:19] <cehteh> but you dont need an inductor then
[08:39:28] <eszett> ah, got it
[08:39:48] <eszett> you said close to the pins, how close is "close"?
[08:39:49] <cehteh> what do you drive?
[08:39:58] <cehteh> as close as possible
[08:39:59] <eszett> is 5 cm close enough?
[08:40:02] <cehteh> no
[08:41:16] <cehteh> directly at the pin, maybe 5mm or so if you cant route it otherwise
[08:41:29] <cehteh> the ceramics
[08:41:42] <cehteh> the wet stuff is not that critical
[08:42:41] <cehteh> an the reset should have an external pullup
[08:42:42] <eszett> alright, i can move them as close as approx. 8mm
[08:43:10] <eszett> won't if function with the internal pullup?
[08:43:51] <cehteh> if unconnected the internal pullup is ok, but when you connect some traces/wires/connectors to it its suggested to add a external pullup
[08:44:42] <cehteh> the internal pullups is quite weak, high resistance, its not enough to prevent accidental resets in all cases
[08:45:07] <eszett> ouch, let me think about it..
[08:45:27] <cehteh> well dunno about atmega32, but others avrs are so
[08:46:13] <eszett> I think i can deactivate the reset function to avoid accidental resets, when the reset button isnt needed
[08:46:40] <cehteh> then you cant reprogramm the chip with a normal ISP
[08:47:07] <cehteh> just add a 0.1cent 5k resistor and you are safe
[08:47:32] <eszett> alright..
[08:47:41] <cehteh> or 1k .. doesnt matter much
[08:47:46] <eszett> 1k then
[08:48:29] <cehteh> thats 5mA over the reset line when reset is closed, but possibly ok
[08:48:50] <eszett> do i have to connect AREF to VCC, or adding a cap to AREF?
[08:49:39] <eszett> (jetzt kapier ich deinen Namen, du hast was mit der C'T zeitschrift zu tun)
[08:52:16] <cehteh> nein mein name Christian T. :D
[08:52:31] <eszett> nagut falsch geraten ahah
[08:52:58] <cehteh> some people also stabilize reset with a small cap, but 0.1µ is way to big, that will make the poweron look like a reset
[08:53:40] <cehteh> AREF needs to be connected as you need it, be careful if wrong connected there can be a short
[08:53:45] <eszett> I see..
[08:53:59] <cehteh> for a cap there (good thing) you need to set a bit in a register somewhere
[08:54:13] <eszett> No need for AREF so I guess I can leave it unconnected to anything, as is.
[08:54:14] <cehteh> if you turn on the internal reference then that voltage is on aref
[08:54:41] <cehteh> yes unconnected is ok there iirc (but read the datasheet)
[08:54:50] <eszett> alright. another question: I have 0.1µF caps on almost all VCC lines. Only UVCC has 1µF, how is that? Is it still common sense?
[08:55:14] <cehteh> i dont know that pin, if the datasheet says so, it should be right
[08:55:39] <eszett> datasheet is keeping quite about it.. i copied the value from somwhere, I believe it was Teensy2.0
[08:55:41] <cehteh> vbus wants 10µ too
[08:55:53] <eszett> ye, forgot the cap on VBUS..
[08:56:14] <cehteh> you can put that close to the usb socket
[08:56:46] <cehteh> also zeners / clamping diodes for the data lines are a good idea
[08:57:31] <cehteh> thats mentioned in the text there
[08:58:21] <eszett> ye.. I will consider this.
[09:55:28] <twnqx> if you connect aref to vcc, add a ferrite + capacitor
[09:55:36] <twnqx> you'll want better filtering
[10:23:44] <cehteh> twnqx: he doesnt want to use the analog part at all
[10:44:38] <eszett> hi twnqx: ye, the analog part isnt necessary for a pc keyboard
[10:44:55] <twnqx> true dat
[10:51:10] <eszett> thanks for discussion. gotta take a nap now, laters!
[11:57:57] <carabia> rue_house, is there a particular reason you have 10 clients hanging around?
[12:00:00] <DKordic> :)
[12:02:55] <twnqx> he can't use a bouncer to multiplex them :P
[12:29:41] <carabia> technically... it wouldn't even be muxing
[12:29:56] <carabia> and i fail to understand why couldn't he
[16:06:44] <rue_house> carabia, 10 computers
[16:07:25] <rue_house> I dont have to do anything but type in the channel I want to from whatever computer I'm at
[16:07:28] <rue_house> 24/7
[16:54:09] <kre10s_> I'm using an atmega48. and having trouble using the watchdog. I want to use it to produce an interrupt every 8s. But only an interrupt. It looks like what I have now is causing an interrupt at 8 seconds and a reset at 16s. I've set WDTON=1, WDE=0, WDIE=1, WDP[3-0]=1001;
[16:54:33] <kre10s_> Is this that 'watch dog safetly' feature playing tricks on me?
[17:01:40] <twnqx> well, you have to rearm the watchdog for it to not reset
[17:01:49] <Lambda_Aurigae> do you reset the watchdog in your interrupt routine?
[17:02:15] <Tom_itx> you gotta tickle it's toes all the time to keep it happy
[17:02:25] <Lambda_Aurigae> hence, watchdog.
[17:02:40] <Lambda_Aurigae> if you don't feed it every so often then it bites you in the ass and makes you reset.
[17:02:40] <Tom_itx> don't feed it after midnight
[17:02:51] <Lambda_Aurigae> Tom_itx, that's the gremlin chip.
[17:03:00] <Tom_itx> ahh that's right!
[17:03:03] <Lambda_Aurigae> just don't get the dang thing wet.
[17:46:11] <kre10s_> What about when the interrupt fires. Do I need to clear the interrupt flag? docs say hardware will reset it but...
[17:46:29] <Lambda_Aurigae> you need to reset the watchdog.
[17:46:34] <twnqx> why exactly don't you just use a timer in the first place?
[17:50:59] <kre10s_> watchdog works in power down mode. timer2 does not
[17:51:41] <cehteh> kre10s_: you have to reset the watchdog interrupt flag else the 2nd watchdog trigger will reset if wd interrupts are enabled
[17:52:49] <cehteh> also consider using an rtc instead the watchdog for that, will be more precise and needs much less power
[17:54:35] <kre10s_> RTC is part of timer2 no? so it won't work in power down mode...
[17:54:51] <cehteh> RTC as in external chip
[17:55:07] <kre10s_> ah. I see what you mean.
[17:55:29] <cehteh> well on some AVR's you can run the timer2 asynchronously
[17:57:48] <cehteh> watchdog is a poor timer, i used that too once, but its more pain than good
[18:01:36] <kre10s_> still. now it's bugging me.
[18:02:50] <cehteh> i've forgotten if you need to ping the watchdog or reset the isr flag when using the watchdog interrupt, just check the datasheet
[18:04:00] <DKordic> Acording to DS it should be just a timer.
[18:05:44] <cehteh> i tihnk it resets when its triggered twice in a row w/o approbiate action
[18:06:03] <cehteh> but i dont remember what that action is
[18:06:33] <DKordic> kre10s_: What is Your test? Have You checked MCUSR?
[18:10:58] <cehteh> kre10s_: ahh .. you have to set WDIE each time *after* a wdt interrupt happend
[18:11:04] <cehteh> that was the trick
[18:11:19] <cehteh> watchdog isr clears WDIE too
[18:11:44] <cehteh> and w/o WDIE enabled it resets the chip on the next watchdog trigger
[18:12:00] <cehteh> so much about reading the datasheet for you .. glhf
[18:13:24] <kre10s_> yes. It's described as a safety feature.
[18:14:08] <cehteh> and do you do so?
[18:56:08] <kre10s_> cehteh, yes I do.
[18:57:40] <kre10s_> I think I'm not initializing it properly. The docs show a code example that sets both WDCE and WDE to enter the 4clk cycle change cycle. why do they set WDE also?
[18:58:02] <kre10s_> shouldn't it be enough to set WDCE only?
[19:16:12] <kre10s__> Why does the wdt_enable routine save the SREG?
[19:22:41] <DKordic> kre10s__: Is also part of the safety mechanism: ``A logic one must. ''
[19:23:06] <DKordic> be written to WDE regardless of the previous value of the WDE bit.''
[19:23:44] <DKordic> I guess to restore I flag.
[19:24:06] <kre10s__> Ah. now that i did not read.
[19:25:15] <kre10s__> Ah. yes. it restores the I flag, because the lib allows you to call it regardless of context.
[19:31:16] <kre10s__> Turns out you don't need to reset the watchdog if you use it in interrupt mode only.
[19:33:26] <cehteh> acctually you must not
[19:33:58] <cehteh> like i saied earlier, when reading the datasheet, you have to reenable the WDIE
[19:36:08] <kre10s__> nope. you must only reenable WDIE if you use it in interrupt+reset mode.
[19:38:45] <kre10s__> 's my experience at least.
[19:39:33] <cehteh> mhm maybe
[19:40:22] <DKordic> So, what was the problem?
[19:41:42] <kre10s__> I was not initializing the wdt correctly. and thinking it was in interrupt mode, when it was in some other mode.
[19:42:57] <kre10s__> lol. suddenly the docs read so clearly.
[21:08:31] <xa0z> So, I have this Digispark tiny85 development board and I can't find anything that will let me put this in dfu mode.
[21:12:42] <Tom_itx> dfu applies to USB chips
[21:12:50] <Tom_itx> tiny85 isn't such a chip
[21:13:10] <Tom_itx> atmega32U2 is such a chip
[21:14:59] <xa0z> Oh, My bad, I didn't realize that.
[21:16:08] <xa0z> I connect this dev board to my USB port and it shows this,
http://pastebin.com/NUvC1j8H
[21:16:29] <xa0z> Guess it's not supported?
[21:22:46] <kre10s__> Tom_itx, the board probably has some usb chip on it to be used to program the tiny.
[21:35:33] <xa0z> For that purpose micronucleus emulates USB hardware as the attiny has no on-board USB device. Communication is done with a host component called micronucleus. On Windows systems it's micronucleus.exe.
[22:20:44] <Tom_itx> kre10s__ but would it be supported by DFU?
[22:21:19] <Tom_itx> xa0z, probably can't help with that
[22:21:41] <Tom_itx> at any rate i'm not sure DFU would work on it since it uses it's on host program