Back
[01:19:51] <rue_house> depends how much your doing, if you only have one interrupt it dosn't matter much
[01:20:19] <rue_house> 99.98% of the time you want to get out of your interrupts as fast as you can
[05:48:35] <hypermagic> _hello my friends
[05:53:53] <specing> well hello there, mortal
[05:56:47] <anandas> hello too
[06:04:15] <hypermagic> what are you creating today ?
[06:07:16] <specing> procrastination [======> ] 40% complete
[08:16:53] <LeoNerd> Downside of using ATtiny breakout boards with decoupling caps already attached: I keep forgetting to add those to the schematic, and hence my PCB layout
[08:17:14] <LeoNerd> Fortunately this time I hadn't sent it to the fab yet
[08:19:12] <twnqx> ... how can you ever forget decoupling caps
[08:19:21] <twnqx> oh well, it's your third board?
[08:19:37] <LeoNerd> Somewhere round there
[08:19:56] <LeoNerd> I just usually use AVR chips in my handy little dev breakouts, and they all have decoupling caps on
[08:20:02] <twnqx> yeah, automatism take a while to kick in :)
[08:20:04] <LeoNerd> So when I'm copying the breadboard into schematic, I don't notice those
[08:31:53] <STS_Patrik> damn those power supply circuits!
[08:36:02] <LeoNerd> So, while I'm here... I'm having trouble trying to work out if I should use short track lengths with vias, vs. longer traces that snake around more but can do so without using vias...
[08:36:10] <LeoNerd> Does anyone have a useful article to read about the subject?
[08:43:18] <LeoNerd> https://www.tindie.com/products/madworm/tiny-avr-isp-pogo-pin-programmig-adapter/ mmmm also, this looks handy for getting nicely small board layouts
[08:43:42] <LeoNerd> 6pin ISP pogo adapter at 50mil spacing
[08:43:57] <LeoNerd> So half the size of the usual 0.1" connector
[08:51:42] <STS_Patrik> I'm using 1.27mm (0.05") pitch ISP & JTAG headers. Built a small 0.1" to 0.05" converter for my dragon
[08:53:25] <LeoNerd> Useful for space?
[08:55:31] <STS_Patrik> yes very
[08:56:08] <STS_Patrik> https://oshpark.com/shared_projects/wC5b2CB8 this is the converter i made
[08:57:01] <LeoNerd> Hmm.. how does that help?
[08:57:20] <STS_Patrik> for my dragon
[08:57:35] <STS_Patrik> i have bought a 1.27mm 10-pin flat cable as well
[08:57:59] <LeoNerd> I don't see how to attach it to the target board
[08:58:31] <STS_Patrik> 1.27mm header as usual ISP or JTAG
[08:58:53] <LeoNerd> Those are just plain copper pads though... What do you use to connect to it?
[08:59:05] <STS_Patrik> SMD headers
[08:59:09] <LeoNerd> Ahh
[09:00:21] <STS_Patrik> so ye, right angle SMD headers
[09:00:34] <LeoNerd> I see... that part didn't jump out immediately obvious
[09:00:47] <STS_Patrik> ye you're right :)
[09:00:55] <LeoNerd> I think I'll use this pogo thing though.. then I don't have to put anything besides copper pads on the target board
[09:02:55] <STS_Patrik> as long as you get the size down
[09:04:09] <STS_Patrik> 0.1" headers feels way oversized on a SMD pcb
[09:04:17] <LeoNerd> Yeah, most definitely
[09:05:32] <STS_Patrik> can't wait until we have a CAN-bootloader running
[09:06:47] <LeoNerd> CAN?
[09:06:56] <vsync_> seriously, what's up with xmega's adc
[09:07:11] <STS_Patrik> CAN-bus, automotive bus
[09:07:27] <LeoNerd> ah.. that. I've not really looked into it
[09:07:50] <LeoNerd> My current big project is an nRF24L01 <-> ATtiny84 board.. I'm hoping to hook it up via SPI/I2C to another ATtiny-driven sensor board...
[09:08:14] <LeoNerd> With some luck I may be able to do ISP of the second tiny over the wireless :) It would avoid having to get physical access to remote sensors
[10:44:57] <vsync_> xmega seems to have a vref per adc port, if i'm using the internal reference voltage i don't need to tie that pin to anything, i can use it as an adc input, correct?
[11:34:25] <Jartza> hmmh
[11:34:35] <Jartza> I have these "clock oscillators"
[11:35:06] <Jartza> if I want to use those with avr, I need to set fuses for "external clock" instead of "external crystal" and connect to clki pin?
[11:35:23] <LeoNerd> Yup... just a clock input pin
[11:36:16] <Jartza> and no need for any capacitors.
[11:36:32] <Jartza> https://www.dropbox.com/s/suw3ojibuavx1w6/IMG_20150119_191510~2.jpg
[11:36:55] <Jartza> strangely I've never used those before, only those crystals
[12:18:55] <zerowidth> Jartza: no external capacitors needed?
[12:19:34] <zerowidth> if i were to set up two attiny chips in the same circuit, what's the best way to hook up one (or two) ISP headers, assuming some of those ISP pins are going to be shared/used for i2c between the two?
[12:20:00] <zerowidth> in particular, the chip that will be the slave will have signals coming in from the other chip, and if i wanted to do ISP stuff with it, how would i prevent that confusion?
[12:21:22] <zerowidth> tie the resets together, so the other chip shuts up for a minute and make sure SCK only talks to one chip at a time?
[12:21:30] <Jartza> zerowidth: no caps needed like with crystal
[12:21:36] <zerowidth> Jartza: neat
[12:22:00] <Jartza> you just give power and gnd to the "metal clock chip" and it gives clock output from one pin
[12:24:36] <zerowidth> Jartza: oh wow, that's a lot more convenient than an oscillator + caps
[12:24:59] <Jartza> yes
[12:25:10] <Jartza> and I wonder why on earth I haven't used these before
[12:25:18] <Jartza> I've had them lying in my component shelf :D
[12:25:30] <LeoNerd> zerowidth: Depends what you're doing with the MOSI/MISO/SCK lines
[12:26:22] <LeoNerd> zerowidth: I have a board with an ATtiny84 and tiny2313 on, talking I2C, so both their SCK and MISO lines are in fact tied together. It's not hard to then arrange that I can tie MOSI too, meaning all three lines are shared by both chips. Obviously they share power, meaning all I have to do is two identical 6pin headers for ISP with individual RESET lines
[12:26:32] <LeoNerd> (that then means I can attach remotely over a 7pin cable)
[12:26:40] <zerowidth> LeoNerd: i'm not sure what the connections will be just yet, but i'm assuming an attiny84 as i2c master --> attiny85 as i2c slave, so SCK and MOSI on the '85 will be used
[12:27:11] <LeoNerd> Alternatively, just give each its own separate 6pin header, then it doesn't matter at all
[12:27:13] <zerowidth> LeoNerd: ah, but if you have the master putting data and clock on the SCK/MOSI, how do you get it to stop talking while you're programming the slave chip?
[12:27:29] <LeoNerd> Eh, I mostly don't bother ;)
[12:27:36] <zerowidth> haha, you just go for it anyway?
[12:27:58] <zerowidth> i'm trying to learn good practices here ;)
[12:28:07] <LeoNerd> Hrm.. I'm not sure I'd call this "good practice"
[12:28:19] <LeoNerd> Largely the reason for my setup is an attempt to talk ISP over wireless
[12:28:34] <LeoNerd> I'm -hoping- I'll be able to ISP into the 2313, via nRF24 module attached to the 84
[12:29:06] <zerowidth> ahh, different problem than i'm trying to solve then...
[12:29:09] <execi> driving avr from a single cell lipo, using an ldo reg to power the circuit with 3v. the reg has an enable pin which would easily be driven with the mcu for power saving mode, however im using the internal rtc of the avr so i cannot power down the whole circuit. wonder if its a good idea to hook up a pmos as a high side switch after the reg and steal power to the mcu before that?
[12:29:22] <zerowidth> but two separate ISP headers would still cause a conflict
[12:29:30] <execi> battery backup is not an option
[12:29:41] <LeoNerd> What sort of conflict?
[12:29:50] <LeoNerd> What do you forsee to break this way?
[12:30:36] <zerowidth> LeoNerd: chip A is talking to chip B with I2C, which uses chip B's SCK and MOSI input pins. if i try and program chip B, won't there be a conflict on B's SCK and MOSI inputs, since A will be putting data on those lines as well as the ISP programmer
[12:30:50] <LeoNerd> Well,.. only if A is talking
[12:31:12] <LeoNerd> Would it still be talking once it fails to get a result from B?
[12:31:30] <zerowidth> LeoNerd: ah, perhaps not! so solve it in software, not hardware?
[12:31:39] <LeoNerd> If it matters that much, you could use some buffer chips on the input lines
[12:31:50] <zerowidth> LeoNerd: i'm wondering if sharing the RST line (but not SCK/MOSI) would make A stop talking too
[12:31:53] <LeoNerd> Maybe have the SCK pin MUX'ed by an A/B switch driven by the RST line
[12:32:15] <LeoNerd> So if you pull down RST to put the chip into ICSP mode, it disconnects its SCK pin from the I2C bus
[12:32:24] <LeoNerd> Actually I might do that on my board
[12:32:55] <zerowidth> ahh interesting. seems i could extend that idea and (with a jumper or something?) select which chip a single ISP header talks to, too?
[12:33:12] <zerowidth> so i could program either chip as desired from one ISP header
[12:33:13] <LeoNerd> If you have physical access that you can use a jumper, sure...
[12:33:25] <zerowidth> this is all just on a breadboard right now, heh.
[12:33:25] <LeoNerd> I'm making remote wireless sensors, so that's a little trickier
[12:33:47] <zerowidth> and if i ever go so far as to make a PCB for it, i'll still have physical access for programming
[12:34:56] <zerowidth> ah,
http://electronics.stackexchange.com/questions/57998/can-i-use-icsp-if-components-share-mosi-sck-pins has some info
[12:35:11] <LeoNerd> Annoyingly, a 74*1G125/126 isn't going to be sufficient, becaues that's unidirectional
[12:35:17] <LeoNerd> I wonder if such a thing as a 1G 4066 exists
[12:35:58] <LeoNerd> Oh -that- 's a setup I've done before and again that works fine
[12:36:19] <LeoNerd> At absolute worst, I just end up clocking a byte or two into the 595 chain, and lighting up LEDs in random patterns
[12:36:43] <LeoNerd> Comment has it: "
[12:36:43] <LeoNerd> flag
[12:36:44] <LeoNerd> Sounds like you might have an amazing light show during programming. That's not a bug, it's a feature! ;-)"
[12:36:48] <zerowidth> haha, right
[12:36:54] <zerowidth> LeoNerd: ah, also it sounds like including isolation resistors is a good idea too
[12:37:18] <LeoNerd> Yah
[12:37:19] <zerowidth> at least on the slaved chip, so anything coming from the master won't interfere
[12:37:21] <LeoNerd> Just in case of driver conflicts
[12:38:45] <LeoNerd> Another thought could be a MOSFET linking each chip's SCK pin to the shared SCL bus, whose gate is driven by the RST line (or a complement of it,.. I can't offhand think)
[12:39:18] <LeoNerd> When not in ISP mode, the channel conducts and the pin works as normal. When in ISP mode the channel is off, isolating that chip from the clock line
[12:42:16] <zerowidth> LeoNerd: actually, lemme step back a second. i'm building a clock, running arduino on an attiny84, which uses an RTC (over I2C) and also talks to a neopixel ring for the actual clock display. problem is, driving the neopixels requires that interrupts be disabled, which means i end up "losing time" since the millis() timer doesn't always trigger, and also serial input via softwareserial isn't reliable since those interrupts don't always trigger either
[12:42:43] <zerowidth> LeoNerd: so i'm thinking about offloading just the rendering stuff to a separate attiny85... but then it occurs to me, maybe I2C wouldn't work either if interrupts aren't enabled...
[12:42:51] <LeoNerd> My thoughts: 1) avoid Arduino. On a 'tiny, doubly-so
[12:43:20] <LeoNerd> I2C isn't at all timing-critical
[12:43:42] <LeoNerd> Offloading the neopixel driver to a tiny85 seems like a great idea
[12:44:04] <zerowidth> LeoNerd: ah, why avoid arduino? i'm mainly using it because it's simple to prototype on an arduino, then scale down for the attinys
[12:44:20] <LeoNerd> Talk I2C using interrupts, use SCL stretching. Master (in the 84) will just have to wait if the 85 is currently busy streaming out bits to the 2812s
[12:44:21] <zerowidth> LeoNerd: i did have to jump through some hoops and rip apart some libraries to get things to fit
[12:44:27] <LeoNerd> Yes, tha'ts what I mean :)
[12:44:36] <LeoNerd> You might as well just not bother, and write directly for the tiny's
[12:44:39] <LeoNerd> tinies
[12:44:43] <LeoNerd> {tiny}s
[12:45:00] <LeoNerd> E.g. use Light_WS2812 for those.. I found that works just fine
[12:45:04] <zerowidth> ah, gotcha. 'course, the once nice thing is that arduino has all the fuse settings and thing so i don't have to look 'em up
[12:45:15] <LeoNerd> "all the fuse settings" ?
[12:45:17] <zerowidth> LeoNerd: yeah, even that wouldn't fit entirely so i had to pull out just the core loop from that lib
[12:45:25] <zerowidth> LeoNerd: well, just for setting the oscillator or whatever
[12:45:27] <LeoNerd> Light_WS2812 fits on a tiny13
[12:45:45] <LeoNerd> http://www.engbedded.com/fusecalc/ <== here. Have a fuse calculator
[12:45:46] <zerowidth> LeoNerd: not with all the other crap i dragged in, heh. (it fits fine now, now that i've simplified a lot of other code)
[12:45:54] <LeoNerd> It even gives you a commandline to copypaste directly into avrdude
[12:46:05] <zerowidth> LeoNerd: mmm, so basically you're saying "don't be so lazy"? :)
[12:46:20] <LeoNerd> Be lazy, just be the -right kind- of lazy
[12:46:50] <LeoNerd> Also, lack of interrupts shouldn't affect you if you write your code correctly
[12:47:07] <LeoNerd> Doesn't your RTC have a "lost ticks" counter or somesuch?
[12:47:34] <zerowidth> LeoNerd: using milliseconds for animation, the time i'm losing is due to the arduino millis() timer not staying up to date because it's based on interrupts (and the ws2812 code disables them when writing)
[12:47:55] <zerowidth> LeoNerd: by using the RTC as a "one second" reference i was able to stretch out the missing milliseconds and get a stable animation
[12:48:30] <LeoNerd> Yes.. does the RTC not perhaps have some way you can resynchronise your counter once you enable interrupts again?
[12:49:01] <zerowidth> that's what i ended up doing in software, basically
[12:49:46] <LeoNerd> I mean, as to your thought of splitting the LED chain out to a separate tiny85, that's still a thing you could do, I just doubt the absolute necessity of it
[12:49:54] <zerowidth> yeah... i'm not sure
[12:50:08] <zerowidth> the other problem is that i'm using the SoftwareSerial library (arduino again) that uses interrupts to track when data's arriving, so it's not always reliable either
[12:50:18] <zerowidth> i guess in that case i could just retry until i see valid data
[12:50:40] <LeoNerd> timing crystal?
[12:50:58] <zerowidth> for which?
[12:51:06] <LeoNerd> I don't usually like to talk serial of any kind (hardware or software) without one, usually the 14.7*mumble* divisible one
[12:51:11] <zerowidth> ahh
[12:51:21] <zerowidth> er, back in a bit
[12:51:30] <LeoNerd> But then I'm currently implementing STK500, which wants 115.2kBaud ;)
[16:13:29] <superbia> good evening
[16:15:33] <superbia> has anyone made a usb keyboard using attiny85, and is it even possible (im looking to make a 50 keys usb keyboard)
[16:16:09] <superbia> i remmember back in the days there was a usb library of somekind.. but my avr days are long past.....
[16:18:40] <superbia> http://i.imgur.com/3G9kusd.jpg like this
[16:25:26] <Shavik> Been using the 328 for a while now and just got my first board with a 324 on it. I know it has two uarts. other than changing the two ISR vect's do you guys know of anything else I need to change? I'm not getting any response from it via serial with code that usually responds on the 328.
[16:25:32] <Shavik> Just wondering if it's anything stupid i'm missing
[16:27:41] <Shavik> This board is also 20mhz when usually I use 16 but I've changed my F_CPU value accordingly
