Back
[07:21:16] <LeoNerd> Gah. Why is this so hard? I want to see a side-by-side picture comparing QFN32 with MLF32 packages
[07:42:06] <LeoNerd> What exactly does the V version of a mega chip do? mega88P vs mega88PV. It seems I can get PVs about 20p cheaper than regular Ps
[07:42:23] <LeoNerd> Oh.. wait no... mega88A vs. mega88PV. Hrm
[07:49:27] <specing> LeoNerd: higher voltage tolerant?
[07:58:46] <LeoNerd> Hrm.. 88PB looks like a fancier chip - an additional SPI ((why you'd need two I don't know)), chip ID registers, and apparently an RTC
[07:59:33] <LeoNerd> But sadly no atomic move-and-clear instructions
[07:59:40] <LeoNerd> Does *any* chip currently have them yet?
[08:05:23] <LeoNerd> Ah. I think I see the difference in the V suffix. The V suffix parts can go down to lower voltage, but have a slower maximum frequency
[08:09:35] <LeoNerd> Oh.. but then the A version goes down that far anyway
[08:15:45] <LeoNerd> Ahah. Such a useful page:
http://real.kiev.ua/2010/09/16/a-and-not-a-avrs/?langswitch_lang=en
[08:15:57] <LeoNerd> Documents the differences between various suffix-versions of the mega chips
[08:25:03] <LeoNerd> Ahah! Also these AVRnnn documents seem useful. E.g. the one titled AVR528: Migrating from ATmega48P/88P/168P
[08:25:04] <LeoNerd> to ATmega48PA/88PA/168PA
[08:25:07] <LeoNerd> ((fscking linefeed))
[08:31:37] <sebus> LeoNerd that frequency limit in AVR family is... ughm... They claimed to work with up to 10MHz (V) but... they work well with faster crystals.
[08:32:30] <sebus> Tested some tiny2313V's in climate chamber under 5V/3,3V at -40 / + 80 celsius. No problem with clocks like 22,1184MHz or so.
[08:32:47] <sebus> same goes to PIC family...
[08:35:02] <LeoNerd> sebus: I expect given how *tiny* the differences are, that what they do is just test chips at the limits and then badge them one way or the other
[08:35:24] <LeoNerd> Though to be fair, the new A variants seem to cover the entire voltage *and* frequency range in a single part
[08:36:18] <sebus> datasheet is your best friend **
[08:36:31] <LeoNerd> It *is* but it's also 450 pages long
[08:36:48] <LeoNerd> So it's really hard to read the mega88A sheet on one side and the mega88PV sheet on the other, looking for differences
[08:37:15] <LeoNerd> This page (and the associated AVR notes) has that all nicely broken down for me
[08:37:21] <sebus> i belive there were shorten versions of datasheets alike several pages or so
[08:37:53] <LeoNerd> Yeah but those again aren't useful for diffs
[08:38:09] <LeoNerd> I suspect what happened with these A variant chips, is that Atmel switched to a new fab process somehow
[08:38:31] <LeoNerd> Basically *every* A variant has different POR voltage levels, minor differences in current consumption in various modes, and that's mostly it
[08:38:40] <LeoNerd> Occasionally chips fix bugs or whatever..
[08:39:27] <LeoNerd> The P?/V? distinction seems to be gone in the A variants... The older series split the range into V=10MHz/1.8V or nonV=20MHz/2.5V, but the newer A variants can manage down to 1.8V or up to 20MHz in a single part
[08:40:24] <LeoNerd> But given I don't need down to 1.8V in my design, and 10MHz will be fast enough, it seems like either 88PV or 88A will do me fine.
[08:52:23] <LeoNerd> Righty. After two hours of Excitingly Entertaining reading of lots of DSes, I have decided that the 14p difference in cost of 88PV vs. 88A isn't worth worrying about; I'll just buy the newer A
[08:53:23] <LeoNerd> It just means now I gotta learn how to heatgun a QFN32
[12:47:41] <BobTheAngryCat> hi noobs and females. What fun can you do with a (CPU + MOBO + [PSU] + RAM)? Can you drive the RAM with an AVR or PIC?
[13:01:30] <sebus> BobTheAngryCat you can write a code to use for eg. sd-ram/simm quite easy
[13:02:12] <sebus> there was also an example of how to emulate arm-like cpu on avr with sd-ram chip and sd-card
[13:05:11] <LeoNerd> Also: It may have been meant in mock jest, but please avoid that kind of borderline-sexist commentary... it doesn't tend to lead to good conversation
[13:07:24] <BobTheAngryCat> sebus: but don't I need some 800Mhz oscillator to use the RAM?
[13:08:01] <sebus> Don't know how it is managed in new ddr2/ddr3 stuff
[13:08:14] <sebus> and so on.
[13:08:26] <sebus> find a datasheet for your ram ICs and study it
[13:45:52] <LeoNerd> Holyfuck these Si86xxx isolators are nice. They're kinda like optoisolators only much much faster
[13:59:28] <LeoNerd> Ohcrap I forgot to order crystals
[14:03:42] <kwallace> "Holycow" would work just as well.
[14:03:54] <LeoNerd> If a crystal says it wants 18pF load, should I take into account the 6pF of the AVR chip itself?
[14:04:05] <LeoNerd> So therefore 12pF caps
[14:29:10] <sebus> LeoNerd yup
[14:29:38] <LeoNerd> I see... to the eBaymatron!
[14:30:25] <LeoNerd> Oh I love eBay for this kind of thing. Type "12pF 0603" in the box, get lots of good results. Two clicks and it's posted
[14:32:38] * sebus uses 15pF in designed stuff
[14:33:13] <LeoNerd> "100 X MLCC, 0603, NP0, 50V, 12PF" <== what does NP0 mean here?
[14:34:03] <sebus> LeoNerd
https://en.wikipedia.org/wiki/Ceramic_capacitor
[14:34:12] <sebus> look there
[14:34:52] <sebus> good choice
[14:35:15] <sebus> low drift ppm/C
[14:39:40] <Lambda_Aurigae> BobTheAngryCat, yes,,,you can drive dram with an avr or pic microcontroller...you have to handle refresh manually.
[14:40:55] <Lambda_Aurigae> BobTheAngryCat, kinda depends on what you are wanting to do and what dram module you are looking at though...ddr, ddr2, and ddr3 would be rather difficult to access properly with an avr but I would think doable....
[14:41:54] <Lambda_Aurigae> 168pin dram should be doable. 72pin simm is definitely doable. 30pin simm is very easily doable and been done multiple times even with a pic16f chip.
[14:42:12] <Lambda_Aurigae> and I've done 30pin sipp (simm with pins soldered on) on a solderless breadboard with an avr.
[14:43:54] <LeoNerd> I imagine as you get to faster memory you also get to faster refresh times needed...
[14:44:19] <LeoNerd> The older 30 or 72pin stuff is down in the msec range, so easily doable on AVR by not taking much extra time away from useful work
[14:45:18] <Lambda_Aurigae> yeah.
[14:45:25] <Lambda_Aurigae> specially with a 20MHz chip.
[14:45:48] <Lambda_Aurigae> but it was doable at 8MHz on a pic16f too.
[14:46:26] <Lambda_Aurigae> which is about 1/16 the speed of an avr at 20MHz
[14:51:30] <LeoNerd> I wonder: do people who keep SMT components, keep them in tapes, or empty them out into little storage boxes?
[14:51:50] <LeoNerd> I got myself some storage box things, little tiny ones with nice lids... but I wonder whether I should just keep them on tape
[15:03:33] <Lambda_Aurigae> LeoNerd, all depends on what works for you.
[15:46:28] <Xark> LeoNerd: I have a few "notebooks" with parts ->
http://www.amazon.com/Adafruit-Blank-SMT-Storage-Book/dp/B00XW2LZRK/
[15:46:39] <LeoNerd> Mmmyes, those
[15:46:48] * Xark notes you get them filled too -> https://www.adafruit.com/product/441
[15:46:53] <Xark> ^can
[15:48:01] <LeoNerd> Oh I don't tend to keep too many sizes as such... I order them in metre strips from eBay
[15:48:14] * LeoNerd *still* waiting for heatgun
[16:19:01] <hetii> Hi
[16:19:17] <hetii> I found such thing in code: #define led_on() do { PORTD |= _BV(6); } while (0)
[16:19:23] <hetii> whats the point of doing that ?
[16:19:43] <LeoNerd> Which part in particular?
[16:19:51] <LeoNerd> Personally I'd write that as #define LED_ON() ...
[16:20:03] <hetii> do while loop to set port
[16:20:16] <LeoNerd> It ensures that the macro body expands to a single statement
[16:20:19] <LeoNerd> It's generally good practice
[16:20:39] <LeoNerd> If the body contained two statements and it wasn't wrapped, then Bad Things would happen if you did something like if(x) LED_ON();
[16:22:39] <hetii> Hmm but can you give some example when preprocesor could fail in this case and not expands it correctly ?
[16:23:15] <LeoNerd> #define LED_ON() DDRD |= _BV(6); PORTD |= _BV(6);
[16:23:19] <LeoNerd> if(x) LED_ON()
[16:23:52] <LeoNerd> Notice that without the do/while wrapping, this expands as if(x) DDRD |= _BV(6); PORTD |= _BV(6);
[16:23:54] <hetii> ahh sure then it fails
[16:23:59] <LeoNerd> So it always touches PORTD
[16:24:32] <hetii> but in given example someone have just one statement
[16:25:12] <Xark> hetii: To be fully "correct" you must add the do { } while [without semicolon].
[16:25:13] <LeoNerd> Yeah, it's not strictly required for one statement. Though equally, it helps turn "bad" expansions into errors
[16:26:34] <hetii> ok thx for explaination I will keep that in mind for trick and hack`s section :)
[16:26:46] <Xark> Also consider if (foo) led_on(); else bar(); If you get an extra semicolon, it will mess up the else (and there are other examples).
[16:27:39] <LeoNerd> To be honest these days, given gcc4.9's LTO, I'd be tempted to write that static inline void led_on() { PORTD |= _BV(6); }
[16:27:50] * Xark links https://stackoverflow.com/questions/154136/do-while-and-if-else-statements-in-c-c-macros
[16:28:20] <Xark> LeoNerd: Not even sure LTO is needed for that to optimize. :)
[16:28:34] <LeoNerd> Well, true if it's in a .h file
[16:28:58] <Xark> LeoNerd: Or in every C/C++ file (same difference - static inline will not make "non inline" version).
[16:30:06] * Xark notes file extension means nothing to a compiler (or having even separate files) - just one big "happy" compilation unit. :)
[16:40:48] <LeoNerd> Is there such a thing as a reverse-facing LED? One that if I mount it over a hole on the board, it would shine through?
[16:41:04] <LeoNerd> I want to put it on the back, behind a touch sensor
[16:43:09] <Lambda_Aurigae> bend the pins.
[16:43:39] <LeoNerd> .. bend.. pins?
[16:45:59] <LeoNerd> Actually I may be able to mount a normal one like this
[16:50:20] <twnqx> also
[16:50:55] <twnqx> there are reverse mount SMD LEDs
[16:52:14] <LeoNerd> Yeah.. I've seen some, but it seems the LEDs I have have metalised ends that go right around the board
[16:52:21] <LeoNerd> So this'll solder in upsidedown just fine